Write CRM Workflow Acceptance Criteria Before the Build

Write acceptance criteria as observable behavior for a defined input, event, and user role. Include what must happen, what must not happen, and how the team will verify both. “Automate lead assignment” is a request. “An eligible unowned inquiry receives the approved destination without changing an existing owner” is the beginning of a testable contract.

Agree that contract with the client before configuration starts. The purpose is to resolve business choices early and make delivery boundaries inspectable. This guide covers authoring criteria for a workflow build. The separate user acceptance test session guide explains how to let client operators exercise the agreed behavior after implementation.

Identify the event precisely

A record being created, a field changing, and a form being submitted are different events. Specify which event starts this workflow, which object it concerns, and which version of the input is evaluated. Clarify whether existing records are included when the workflow is first enabled.

For a hypothetical inbound routing component, define the trigger as a new inquiry received through an approved source. Do not let “new lead” silently expand to imported historical contacts or every update to a contact record.

Write down how later changes are treated. If the inquiry's service line is corrected after assignment, does the component reassign it, create a review task, or leave it unchanged? Each choice changes acceptance. The client process owner should make that choice; the implementer can explain feasible options and their consequences.

Use one criterion for one consequential rule

Give each criterion an identifier, preconditions, event, expected outcome, forbidden side effects, and evidence method. Related criteria may share a scenario, but a tester should be able to identify which rule failed.

An illustrative criterion could read:

ROUTE-01: Given a new inquiry with an approved service-line value, a uniquely resolved contact, and no existing owner, when the routing component processes the inquiry, assign the destination listed in the approved routing table. Preserve the source inquiry identifier. Do not create a second contact or send an external message. Verify the destination, preserved identifier, record count, and action history in the test environment.

This example proposes behavior rather than claiming any particular CRM implements it natively. The team must confirm what can be observed in the actual environment. If action history is unavailable, agree another evidence method before accepting a test that depends on it.

Keep the routing table version attached to the criterion. A phrase such as “assign to the right team” is untestable when the correct destination changes between build and review. Use lead routing rule design to settle the destination policy; acceptance criteria reference that policy instead of inventing a second one.

Write the non-action cases explicitly

An exclusion is a requirement. Test records that should remain unchanged, especially when the component touches ownership, customer communications, or associated objects.

For the same example, prepare a decision table:

Input condition	Proposed expected behavior
Valid service line and no owner	Assign using the approved table
Existing owner	Preserve ownership and record the exclusion if supported
Missing service line	Route to the agreed review path without guessing
Two possible contact matches	Hold for identity review; do not update either match
Event already processed	Follow the agreed repetition rule without a duplicate action

The table is a starting point for a client decision, not a universal routing policy. Ask the client to approve each row. If an unknown value is allowed to proceed, specify the fallback and its owner. Do not make a tester infer that unknown means false, empty means default, or an old record is automatically out of scope.

Define completion across system boundaries

A workflow can report success before its business outcome exists. If the component calls another system, specify whether acceptance requires a request to be queued, a destination record to be created, or an operator to complete a follow-up. These are separate milestones with different evidence.

For an asynchronous integration, define where the pending state is visible, what identifies the same operation across systems, and which observation establishes completion. Agree an observation window appropriate to the actual system and operating arrangement. Avoid words such as “instantly” or “eventually” when neither gives the tester a decision point.

An unavailable destination and an unknown outcome also need distinct criteria. When an update may already have completed, blindly repeating the call can produce another side effect. Refer to retry and idempotency design to define the operation identity and reconciliation behavior. Accept only the behavior actually supported and tested; a connector label does not establish safe repetition.

Make the evidence plan executable

For every criterion, state how to prepare the starting data and inspect the result. Record the user role, environment, configuration reference, input identifier, expected values, observed values, and evidence location. A tester should not need the original implementer to reconstruct the setup.

Use safe representative data and the permissions expected of the real operator. Administrator access can conceal a task that an ordinary user cannot perform. If an essential action cannot be tested safely, mark it blocked or not tested and identify who can resolve that limitation.

Distinguish a system test from a manual simulation. Demonstrating the intended outcome by manually setting a field helps explain a design, but it does not prove the automation made the change. Keep those evidence types separate in the acceptance record.

Resolve ambiguity before it becomes a defect argument

During review, challenge words such as valid, duplicate, ready, fast, and complete. Replace each with an agreed definition or a reference to an authoritative rule. Ask for one case that passes and one nearby case that does not. Boundary examples often expose disagreement that a broad sentence conceals.

If the client cannot decide, record the unresolved choice and affected criteria. Independent work can proceed, but the affected behavior remains provisional. Do not configure a convenient default and present it later as an approved requirement.

When a platform limitation prevents the intended behavior, document the limitation, the alternative, and the revised acceptance boundary. Obtain the client's decision before treating the alternative as delivered. A workaround may be acceptable, but changing the criterion after a failed test must remain visible.

Use criteria to control the release decision

Map implemented components and test cases back to criterion identifiers. Classify each result as pass, fail, blocked, or not tested. Retain failed observations and link fixes to retests. A percentage pass rate can conceal the only failure that matters, such as an excluded record receiving a customer message.

Ask the client acceptance owner to review the evidence, open failures, and any explicitly accepted deviations for the identified version. Record scope and limitations with the decision. Passing the agreed cases supports acceptance of that tested scope; it does not prove every possible CRM condition has been exercised.

After release, new requests should identify which criterion changes or which new behavior is added. This gives the consultancy a concrete distinction between correcting a broken promise and expanding the workflow. The result is a build whose completion can be discussed from shared evidence instead of competing interpretations of a short request.