Projects, boards, issues and sprints
Organise work in Fulcrum CRM projects, track issues on boards, use sprints and acceptance criteria, and review project permissions and delivery evidence.
The project workspace organises delivery beyond a customer record. Its availability depends on module access and permissions. It supports projects, issues, boards and sprints; a project can represent software, business, marketing or operations work.
Create a focused project
- Open the projects workspace and choose Create your first project or the new-project action.
- Give it a clear name, identifying key and appropriate type.
- Review its access and membership before adding business material.
- Create an initial issue with an owner, context and an observable outcome.
Issues and acceptance criteria
An issue represents a unit of work. Write what should happen, the relevant context and how the result will be checked. Use acceptance criteria to distinguish “implementation exists” from “behaviour works.” Include a reproduction for a bug and links to the source record where appropriate.
Boards and views
Use board and list views to organise work by state. Calendar and timeline views help inspect dates and sequencing. Check view filters before assuming an issue is missing. Moving an issue changes its workflow state; it does not execute the underlying task.
Sprints and delivery
Use a sprint to group a bounded set of issues. Check capacity and dependencies before committing work. When completing a sprint, review unfinished issues rather than treating the sprint closure as proof of delivery. Reports and retrospectives are most useful when issue state and dates reflect what actually happened.
Comments, attachments and development context
Keep decisions and evidence in the issue discussion, with attachments limited to the intended audience. Development links can connect an issue to source changes. A linked commit alone does not prove a release is deployed; record test and live-verification evidence when deployment is part of the work.
Permissions and recovery
Check project and board permissions before inviting collaborators. If an issue is not visible, confirm the project, filters and access first. Avoid deleting a project to fix a view problem: it can contain issues, comments and delivery history that the team still needs.
Last updated