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

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.

Related: Status and milestone-date modeling, History and snapshot design, and Metric ownership and source of truth.