Feature · CRM Workflow

How work flows through the record, stage by stage.

Every entity on Strkr with a lifecycle (lead, opportunity, task, project, issue, case) carries a workflow: a set of stages, the transitions between them, the rules that gate each move. The grammar is consistent across modules; teams learn it once and apply it everywhere.

Start free trial See pricing
The grammar

Stages, transitions, gates, actions.

A workflow on Strkr is a state machine. The record sits in exactly one stage at any time. Transitions move the record from stage to stage; gates control which transitions are allowed; actions fire on entry or exit. The grammar is deliberately small so teams master it in an afternoon rather than a quarter.

Stages

Ordered buckets with semantics.

A workflow defines an ordered list of stages. Opportunity stages typically run Prospecting, Discovery, Proposal, Negotiation, Closed Won, Closed Lost. Each stage carries a semantic (open vs closed, forecasted vs excluded, won vs lost) that drives pipeline math and reporting. Reps see stages as columns on the pipeline board.

Transitions

The allowed moves between stages.

Transitions specify which stage-to-stage moves are allowed. A linear workflow allows only forward moves (Prospecting to Discovery, never Prospecting to Negotiation). A free workflow allows any move. Most teams land in between: forward is free, backward requires a reason, closed states terminate. The transition shape is a tenant configuration.

Gates

Required conditions before a move completes.

A transition can carry a gate: a condition that must evaluate true before the move completes. Opportunity moving to Proposal might require the primary contact field populated, the amount set, the close date within the forecast quarter. The gate blocks the move with a error message; the rep knows exactly what to fix.

Entry actions

Side effects on stage entry.

An entry action fires when a record arrives in a stage. Opportunity entering Proposal might trigger proposal-draft generation, enroll the account in the proposal-review sequence, create a 48 hour follow-up task on the owner. Entry actions turn a stage change from a label swap into a workflow event with downstream consequences.

Exit actions

Side effects on stage exit.

An exit action fires when a record leaves a stage. Opportunity leaving Negotiation to Closed Lost might trigger loss-reason capture, enroll in a reactivation flow if the loss reason is timing, notify the AE manager if the deal size exceeded $100K. Exit actions let the workflow react to departures without the rep taking extra steps.

Required fields

Fields that must be present per stage.

Each stage can define required fields that must be populated for the record to sit in that stage. Opportunity in Discovery requires discovery notes; in Proposal requires decision maker identified; in Negotiation requires close plan documented. The requirements render as a stage-exit checklist; reps see what is missing without hunting through the record.

Workflow per entity

The same grammar across every record type.

Workflow applies to every entity with a lifecycle. The grammar is uniform; the specifics differ by entity. Teams learn the pattern on opportunities, then apply the same pattern to leads, cases, projects, issues. The uniformity cuts training time by roughly 60 percent compared with per-entity bespoke rules.

Lead workflow

New, Qualifying, Qualified, Converted, Lost.

Lead workflow runs five stages by default. New captures inbound before touch; Qualifying covers active outreach; Qualified records with budget authority need and timeline; Converted shifts to Opportunity creation; Lost captures the reason. Conversions create the opportunity record and preserve the lead-to-opp link for attribution.

Opportunity workflow

The canonical pipeline shape.

Opportunity workflow is the shape most CRM users recognize: Prospecting, Discovery, Proposal, Negotiation, Closed Won, Closed Lost. Each stage carries forecast posture (committed, best-case, pipeline, excluded), probability percent, and typical duration metrics. Reports slice the pipeline on stage, forecast posture, and velocity.

Case workflow

Support ticket lifecycle.

Support cases run through New, Assigned, In Progress, Pending Customer, Resolved, Closed. SLA clocks run per stage transition; a case in Pending Customer pauses the response SLA. Reporting rolls up resolution time, first-response time, and reopen rate per queue and per agent.

Project workflow

Project module stages per type.

Project types carry their own workflow. A client implementation runs Kickoff, Discovery, Build, UAT, Launch, Hypercare, Closed. An internal initiative runs Proposed, Approved, In Progress, Review, Done. The per-type pattern lets diverse work live in one Projects module without forcing every team into one shape.

Issue workflow

Agile issue states.

Project issues run through Backlog, Selected for Sprint, In Progress, In Review, Done. Agile teams layer on sprint assignment and story-point estimation. Dependencies between issues (blocks, is-blocked-by, relates-to) render on the issue detail; a dependency the issue blocks surfaces on daily stand-up prep.

Custom entities

Build a workflow on a custom object.

Custom objects (loan applications, service work orders, grant submissions) carry their own workflow. The admin defines stages, transitions, gates, and actions in the same editor. Reports and automation treat the custom entity identically to the standard ones. Teams in verticals with unique motions build without engineering intervention.

Fork and merge

Workflows per team, with legal shared.

A large tenant with multiple business units often needs team-specific workflow shapes. The commercial AE team runs a different opportunity workflow than the enterprise AE team runs than the SMB team runs. Strkr supports workflow forks per team with controlled merge paths for shared stages.

Shared base

The tenant workflow is the parent.

The tenant-wide workflow serves as the base. Shared stages (Closed Won, Closed Lost), shared gates (minimum amount, required decision-maker), and shared actions (CRM Closed-Won fan-out) live on the base. Team forks inherit the base and extend; changes to the base propagate to forks on next publish.

Team fork

Each team customizes without rebuilding.

A team fork adds stages or modifies gates specific to the team motion. Enterprise AE team might add a Legal Review stage between Negotiation and Closed Won; the SMB team might collapse Discovery and Proposal into a single Qualify stage. The fork preserves inheritance from the base; nothing is a clone that drifts over time.

Override gate

Team-specific requirements per stage.

Teams can override gates per stage. Commercial team requires a close plan at Negotiation entry; enterprise team requires legal-reviewed MSA at Negotiation entry. The override is additive to the base; a tenant-wide required-field cannot be removed by a fork. The posture prevents compliance drift through fork manipulation.

Promote changes

Team-tested patterns flow up.

A workflow change tested on one team fork can promote to the tenant base. The promotion diff shows the proposed changes; the admin approves. Patterns that proved out on the pilot team ship to the rest of the org without a separate rebuild. The promotion mechanism supports gradual rollout of workflow improvements.

Shared reports

One pipeline across forks.

Reports roll up across forks on shared stages. The CRO sees total pipeline across commercial, enterprise, and SMB on Closed Won; the intermediate stages differ per fork but the terminal states align. The report design treats forks as views, not separate datasets.

Permission scope

Workflow authoring scoped per team.

A team manager can author the team fork without needing tenant-wide workflow permission. The scoping lets teams iterate without going through the admin bottleneck. Tenant-wide base changes still require the tenant admin permission; the two scopes layer cleanly.

Workflow observability

Where are records getting stuck.

A workflow without observability is a theory. The workflow analytics shelf shows how records flow through stages, where they stall, who moves them, and how long each stage takes. The data drives coaching conversations and workflow refactors with evidence.

Stage distribution

Count of open records per stage.

The pipeline distribution chart shows how many open records sit in each stage, sliced by owner, team, and territory. A pipeline bulging in Discovery and thin in Proposal usually indicates a qualification bottleneck; the shape surfaces the problem before the quarter closes short.

Stage velocity

Median days in each stage.

Velocity reports show median and 90th-percentile days in each stage, with trend over quarter. A stage velocity creeping up by 20 percent over three months indicates a motion decay; the ops lead drills into the records to find the pattern (new rep, new product, new market segment).

Transition rate

Percent of records that move forward.

Transition rate reports show the percent of records that moved out of a stage in a given window, split by forward move versus backward versus closed-lost. A stage with 60 percent closed-lost rate deserves scrutiny; the shape might be a qualification problem or a product-market-fit problem, which the drill-in distinguishes.

Stuck records

Records that have not moved in N days.

A stuck-records view lists open records that have not transitioned in a tenant-defined window per stage (Discovery 14 days, Proposal 21 days, Negotiation 10 days). Managers open the view on Monday and triage with the owner. The view is also a flow trigger input for automated nudges.

Transition audit

Every stage move writes to the log.

Each stage transition writes an audit entry with timestamp, record ID, from-stage, to-stage, user, and the reason if the transition required one. Compliance teams and operational reviewers reconstruct any record history in one query. The entry chain is tamper-evident per the standard audit log posture.

Workflow version timeline

See how the workflow itself evolved.

Workflow versions are tracked separately from record data. A regression analysis on sudden stage velocity change can cross-reference the workflow change log; a new gate added last Tuesday might explain the sudden spike in records held in Discovery. The dual timeline (records plus workflow) makes forensics tractable.

When to redesign a workflow

Signals that the shape is working against the team.

Workflow design is not static. The right shape evolves with the business. Teams that run a Monday pipeline review and open a workflow refactor conversation twice a year typically outperform teams that touch the workflow once at implementation and never revisit. These are the signals that redesign is overdue.

Signal one

Reps bypass the workflow with notes.

When reps park important context in notes rather than fields, the workflow is not capturing what the team actually tracks. The fix is adding fields to the right stage and adjusting gates. The bypass pattern is visible in the activity timeline; a stage transition without a corresponding field update usually indicates workflow drift.

Signal two

Managers run shadow spreadsheets.

A manager maintaining a side spreadsheet for pipeline review is a sign the native workflow reporting does not surface what the manager needs. The fix is usually a report redesign; sometimes the fix is a stage addition that captures a motion the current shape ignores. The pattern erodes the single-source-of-truth promise.

Signal three

A stage has over 50 percent of pipeline.

When one stage holds the majority of open pipeline, the workflow is probably too coarse-grained at that point. Discovery holding 60 percent of pipeline suggests splitting Discovery into Discovery and Qualification. The split surfaces the motion detail; the alternative is a mystery pipeline chart that cannot distinguish early-stage from late-stage prospects.

Signal four

Closed Lost reasons cluster around no decision.

When loss reasons cluster around indecision rather than competitive loss or budget, the qualification motion is admitting prospects that should never have moved past New. The fix is tightening the Qualifying-to-Qualified gate. The signal is visible on the loss-reason report; the fix is a 15 minute workflow edit.

Signal five

Stage velocity varies wildly by rep.

When one rep spends 8 days in Discovery and another spends 32, either the reps are running different motions (coaching opportunity) or the workflow is forcing one motion onto two incompatible shapes (fork opportunity). The velocity-by-rep report surfaces the variance; the fix is situational.

Signal six

New product line does not fit the shape.

A newly launched product with a different sales motion (shorter cycle, different buyer, lower AOV) often does not fit the existing opportunity workflow. The fix is a workflow fork for the product line. The alternative of forcing all deals into one shape distorts both the reports and the rep experience.

Audit your opportunity workflow in thirty minutes.

Share your current pipeline shape; we will walk through stage distribution, velocity, stuck records, and the two or three edits that typically improve conversion inside a quarter.

Book a workflow audit See pipeline stages
Common questions

What buyers ask about this feature.

How many stages should an opportunity workflow have?

Four to six stages fits most mid-market teams. Fewer than four tends to collapse important motion detail into a single bucket; more than seven tends to produce stage ambiguity (is this Discovery or Qualification). The right count varies by sales motion complexity: transactional SMB sales often run four stages (Prospecting, Qualified, Proposal, Closed); enterprise sales often run six to seven (adding Discovery, Technical Validation, Legal Review). The pattern is less about count than about whether each stage captures a distinct motion the team actually runs.

Can we move a record backward in the workflow?

Yes, if the workflow configuration allows backward transitions. Most teams allow backward moves with a reason-capture gate; the record carries the reason and the audit log preserves the full transition history. Some teams restrict backward moves to specific roles (manager only) to prevent reps from quietly re-opening lost deals. The backward-move posture is a tenant configuration; neither direction is forced.

What happens when we change the workflow mid-quarter?

Workflow changes publish to a new version while the previous version continues running against records already in flight. New records enter the updated version; records in flight finish their current stage under the old rules and transition to the new rules on next stage change. The versioning posture lets teams iterate without disrupting active deals. The admin dashboard shows version-adoption state across the pipeline.

How do workflows integrate with Strkr Flow automation?

Workflows and flows are complementary. The workflow defines the structure (stages, gates, required fields); the flow defines the automation that runs on top (notifications, enrollments, external integrations). A stage transition is a trigger that Strkr Flow listens to; a flow condition can check workflow state; a flow action can transition the record forward. The two work together in roughly 70 percent of production motions.

Can different modules have different workflow concepts?

The underlying grammar is uniform across every module (stages, transitions, gates, entry and exit actions). The specifics are per-entity: a case workflow runs SLA clocks that an opportunity workflow does not run; a project workflow carries milestone-dependency semantics that a case workflow does not need. Teams that learn the pattern on one entity apply it to others with minimal retraining; the module-specific extensions sit on top of the common grammar.

How does workflow permission work for team managers vs admins?

Workflow permissions split into two scopes: tenant-wide (edits the base workflow, affects everyone) and team-scoped (edits a team fork, affects only that team). Team managers typically carry the team-scoped permission; tenant admins carry both. The split lets team managers iterate on their fork without going through the tenant admin bottleneck. Audit logging captures the authoring user on every change so attribution stays clear.

Related features

Pair this with...

CRM with Workflow Automation CRM Automation Examples CRM Pipeline Stages Automate Workflow CRM Document Automation Strkr AI Workflow

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing