What makes a workflow reportable?

The workflow records the population, states, milestone dates, owner, source of each important field, suppression and failure reasons, and the event that proves completion. A dashboard cannot repair missing process evidence.

Reporting-ready workflow design

A report can only show what the process recorded. Design the reporting fields while you design the work.

Process fields to define first

Field group	Minimum model
Identity	Stable subject and run ID
Population	Why the item entered
State	Waiting, running, completed, suppressed, failed
Milestones	Triggered, owned, accepted, completed
Ownership	Team, person, and transfer event
Outcome	Allowed business result
Exceptions	Reason code and next owner

Use controlled values for states and outcomes. Put explanations in a separate note or event record.

Status is current state, dates are history

status = completed tells you where the record is now. completed_at tells you when it got there. Keep both. A current owner field cannot answer who owned the item last week.

Store the question with the process

For each workflow, write one reporting question before choosing a chart:

Question: How long do accepted inbound requests wait before a seller owns them?
Population: Requests with decision outcome route-to-seller
Start: seller_ready_at
End: seller_accepted_at
Exclude: suppressed before assignment
Owner: sales operations

This prevents a broad dashboard from becoming the specification.

Platform path

Use native CRM fields and reports for current-state and milestone questions. Add an event or snapshot model when the question is about what the record looked like at earlier points. Verify current object, workflow, and reporting features in the Salesforce reports documentation and HubSpot reporting documentation.

Start from the review question

Write the questions an operator and leader will ask before implementing the workflow: how much entered, where is it now, how long has it waited, what completed, what failed, what was suppressed, and who owns the next move? Each question should map to a stored state, event, timestamp, reason, or owner.

Record workflow and policy versions with each run. Preserve eligibility and terminal reason codes. Use milestone timestamps rather than deriving history from the current status, and keep a stable run ID when one business record can enter more than once. Define unknown and bad-data states instead of letting nulls disappear from reports.

Test reporting with the workflow

Before launch, run records through success, rejection, suppression, retry, timeout, manual completion, and reopen paths. Confirm each lands in the expected report population and can drill back to its history. Reconcile entered records to all terminal and open states. A workflow is not complete when the action fires; it is complete when the business can operate and evaluate what happened.

Apply the same design to pipeline reporting

Pipeline reporting is a workflow-history problem. A current Opportunity stage cannot tell you when the deal entered, whether it regressed, how often the Close Date moved, or which qualification definition was active at the time.

At minimum, preserve:

Pipeline event	Evidence to store
Qualified entry	Qualification result, accepted timestamp, definition version
Opportunity creation	Created timestamp, source motion, originating person or Account
Stage movement	Prior stage, new stage, event time, writer, required evidence
Amount or Close Date change	Before, after, event time, change source
Forecast change	Prior category, new category, event time, owner
Closure	Won or loss timestamp, reason, final amount, final stage
Reopen	New evidence, reopened timestamp, relationship to prior history

Build the current pipeline from current state. Build conversion, velocity, movement, and forecast-change reporting from events or snapshots. The Opportunity stage contract defines what each transition means; this page defines what the process must retain so the report can prove it.