A tour of Strkr's Projects module

Most CRMs treat the deal as the end state. The pipeline ends at Closed Won, and whatever happens next lives in a separate tool. For teams delivering a service, a project, or a managed engagement, that handoff is where the money is made or lost. Strkr’s Projects module is the delivery layer that lives on the same data model as the CRM, so the handoff is a config choice, not an integration project.

This post is a tour: what the module does, how it connects to the rest of the workspace, and the workflows teams typically have running in their first week.

What Projects is

Projects is a work-management module inside Strkr with issues, epics, sprints, releases, roadmaps, goals, and automations. Think of it as a Jira-shaped surface for shipping work, but reading from the same tenant data as your CRM.

The core objects:

• Projects. The top-level container. One project usually equals one client engagement, one internal initiative, or one product workstream. Projects have templates, so a new engagement spins up with the right pipeline stages, roles, and default settings.
• Issues. The work unit. Issues have type (task, bug, story, epic), priority, assignee, estimate, due date, status, and up to 14 custom field types including lookups to CRM records.
• Epics. Groupings of issues that ship together. Epics live inside projects and roll up progress automatically.
• Sprints. Time-boxed delivery windows. Sprints hold issues, support capacity tracking per assignee, and produce burndown reports.
• Releases. Named deliveries. Releases bundle issues shipped together, generate changelogs, and track against goals.
• Goals. Quarterly or project-level objectives with key results that pull from issue data.
• Roadmap. A Gantt-style view across all projects with epic bars, sprint swimlanes, and drag-to-reschedule.

Every object shares the tenant data model, so a project can reference an Account from CRM, an issue can be assigned to a Contact, and an epic can roll into a renewal opportunity.

How Projects connects to the CRM

The handoff from CRM to Projects is the whole point. In most CRMs, this is a manual export plus a kickoff meeting plus a new tool with new logins. In Strkr it is a flow.

The default handoff pattern:

1. A deal moves to Closed Won in CRM.
2. A flow in the no-code flow builder fires with the deal as context.
3. The flow creates a project from the right template (based on deal.industry, deal.type, or any other field), copies over scope hours, delivery lead, and client contacts, and assigns a project manager.
4. The project appears in the Projects tab on the account record in CRM.
5. The AE sees status without leaving CRM. The delivery team opens Projects to work.

Customers typically build this handoff in the first week on the platform. It eliminates the recurring “export deal to project tool” overhead and keeps client context attached to the delivery work from day one.

The surfaces you actually use

Teams spend most of their time in six surfaces inside Projects. Here is what each one covers.

1. The Board view

Standard kanban with issues flowing left-to-right across status columns. Density control, color-by picker, group-by popover, and a sprint strip at the top. Assignee filter and search are built in. Issue cards show type, priority, assignee avatar, story points, epic reference, and inline edit buttons.

Teams use the Board for daily standups and sprint execution.

2. The Backlog view

A sortable list of all unscheduled issues with inline edit, drag-into-sprint, and per-assignee capacity bars. Multi-select plus a bulk action bar for mass updates (change priority, reassign, add to sprint, add label). CSV export for anyone who still wants a spreadsheet view.

Teams use the Backlog for sprint planning and refinement sessions.

3. The Sprint view

Current sprint scope with metric cards (committed vs completed, scope change, velocity), a burndown chart, a by-assignee progress bar, and a scoped Board view. OOO drawer handles vacation and sick days so capacity math reflects actual availability.

Teams use Sprint view during the sprint for progress tracking and for retrospectives at the end.

4. The Roadmap view

Gantt timeline across all projects. Sprint swimlanes, epic bars, dependencies, and a today marker. Drag-to-reschedule works directly on the timeline. Three modes: time view, swimlane view, dependency view.

Leadership uses the Roadmap for cross-project visibility and resource planning.

5. The Issue page

The full issue detail: rich-text description, comments, activity timeline, linked CRM records, child issues, dependencies, time estimates, custom fields, and attachments. #ISSUE-KEY references autolink everywhere.

Teams use the Issue page for everything a ticketing system does.

6. The Reports tab

Per-project reports: throughput, cycle time, work in progress, escaped bugs, sprint predictability. CSV export per report. Period toggle (30d, 90d, YTD).

Teams use Reports for retrospectives and leadership reviews.

The automations layer

Projects has its own trigger surface in the no-code flow builder. Available project triggers include:

• Issue created, updated, deleted, or specific field changed
• Issue status transitioned (with before/after state)
• Sprint started, closed, or scope changed
• Release created or shipped
• Project milestone reached
• Goal key result updated

Actions span the full module library: create or update issues, move between sprints, assign owners, post to Slack, fire a billing alert in CRM, flip a renewal risk field, or trigger a second flow.

Teams typically run three to five project automations in their first month:

1. Deal closed → project kickoff (the handoff flow above).
2. Issue status moved to Done → notify client stakeholder (for engagements where the client wants a signal when a milestone ships).
3. Sprint closed → auto-roll incomplete issues to next sprint (saves 10 minutes of manual sprint hygiene).
4. High-priority issue created → page the on-call delivery lead (service-tier teams only).
5. Project milestone complete → fire billing alert in finance (for milestone-billed engagements).

Permissions and roles

Projects uses Strkr’s workspace role model plus a per-project membership link. A user can be a workspace admin, a workspace member, and have a per-project role on top (lead, member, viewer). Project leads get implicit permissions on sprint, release, goal, member, and customize operations without needing to touch the workspace role.

This matters for agencies and services firms with multiple clients: the client’s internal champion can be added as a Viewer on their project without seeing other clients’ work.

When Projects is the wrong tool

Three cases where another tool fits better:

1. Design and creative production workflows. Figma, Frame.io, and specialized creative tools handle creative review and asset management better than any work-management tool. Projects can hold the project record and the delivery tasks; the creative work lives in its own tool.
2. Highly specialized engineering workflows. Teams on Jira with 15 years of custom Jira workflows, test automation hooks, and release pipelines wired through Jira will not get full feature parity by moving to Projects. The right pattern is to leave engineering on Jira and run client delivery, project management, and PM workstreams in Projects.
3. Pure personal task management. Projects is a team work tool, not a personal to-do app. Teams of one are better served by Things, Todoist, or a note tool.

For services firms, consulting shops, agencies, and SaaS delivery teams, Projects is a direct replacement for the generic PM tool they are running alongside their CRM today.

How to try it

Projects is a per-workspace add-on module. The 14-day Strkr free trial includes Projects at the full feature level, so you can build a real workflow end-to-end before any charge. Pricing at strkr.io/pricing.

Related reading: How Strkr’s no-code flow builder actually works covers the automation surface that connects CRM and Projects, and How to choose a CRM: a practical buying framework walks through the five questions that determine whether an all-in-one platform is the right shape for your team.