Write Salesforce acceptance criteria by naming the user, the starting situation, the action and the result that must be observable. Add the important exceptions, identify who can accept the outcome, and agree on the evidence before configuration begins. A request such as "automate onboarding" is an opening conversation, not a testable finish line.
The practical question is simple: could a business user and an implementer look at the same result and independently agree whether it passed? If one means "the flow ran" and the other means "delivery received everything needed to start," the project still has a requirements gap.
Describe the work before choosing the feature
Start with the person doing the work and the problem they need solved. For example: after a sale is confirmed, the delivery coordinator needs an accurate onboarding handoff so they can assign the work without asking the seller to reconstruct the agreement.
That statement creates several useful questions. What confirms the sale? Which agreement is authoritative? What information does delivery need? Who owns incomplete handoffs? None of those questions is answered by deciding to build a Flow.
Salesforce's user story guidance describes acceptance criteria as clear, independently testable conditions and recommends stating intent rather than prescribing an implementation. The team can choose the technical approach once it understands the required behavior.
The implementation pitfalls discussion makes a related point: delivering exactly the requested component can still miss the business need. Acceptance criteria make that need concrete enough to discuss, build and verify.
Turn one vague request into a worked example
Consider an illustrative request: "When a deal closes, notify onboarding." This is a hypothetical workflow, not a client's implementation or a claim about default Salesforce behavior.
For this example, sales and delivery agree that a handoff is ready only when the opportunity is Closed Won, the accepted quote version is identified, an onboarding contact is present and a delivery owner has been assigned. They also agree that the handoff contains the scope reference and requested start date. These are example business rules; your team must define its own.
The first criterion could be:
Given an authorized seller and a deal with the agreed handoff information complete, when the seller submits it for onboarding, the assigned delivery owner can find one handoff linked to the opportunity and accepted quote version, with the agreed scope reference, contact and requested start date.
This describes an outcome the receiving team can inspect. It does not dictate a button, object, notification channel or automation product. Those design choices still need to be made, but the team now has a shared target.
Break the result into separately testable checks if it is too large for one clear pass or fail. A handoff may exist while its quote reference is wrong. Recording those checks separately makes a partial failure visible.
Write the cases that reveal disagreement
The ordinary successful case is necessary. The exceptions often expose the decisions that would otherwise surface during testing or after launch.
Required information is missing
Given the onboarding contact is absent, when the seller attempts submission, the handoff does not become ready for delivery. The seller can identify the missing information and the next action. A permitted exception, if one exists, must have a defined approval path.
Agree whether an incomplete draft may be saved. Preventing readiness and preventing every save are different requirements. A seller should not have to invent a contact merely to preserve unfinished work.
The wrong person attempts an action
Given a user who is not authorized to submit the deal, when that user attempts the action, the handoff is not submitted and no unauthorized change is saved. An authorized delivery coordinator should still be able to see the information required for their role.
Test the relevant user roles, including their actual record and field access. An administrator successfully completing the path does not establish that a delivery user can perform it, or that a restricted user cannot.
The request is repeated
Given a handoff already exists for the same approved business event, when the submission is repeated, the intended outcome is still one handoff for that event. The user can find the existing result instead of creating another onboarding assignment.
The implementation team must define and test how that identity is enforced, including competing submissions if relevant. Acceptance criteria specify the required result; they do not prove that a lookup before creation is enough to guarantee it.
The agreement changes afterward
Given delivery has already received a handoff, when an authorized amendment changes the accepted scope, the delivery owner can identify the changed agreement and the required next decision. The original handoff history remains understandable.
Decide whether the change updates an existing handoff, creates a revision or requires a separate approval. Do not let an implementer settle that commercial decision accidentally through whichever update is easiest to configure.
Agree on evidence while the example is small
Use representative test records and a named tester for each role. Record the expected result before running the test, then capture what actually happened. The evidence should identify the requirement, test data, user role, result and any defect that prevents acceptance.
For the successful onboarding case, useful evidence includes the saved handoff, its source references and what the delivery coordinator can access. A screenshot of a success message alone may not show whether the correct values were saved or whether the receiving team can use them.
For a failure case, inspect both the message and the resulting state. A warning can display while an unintended record is still created. Likewise, no visible error is not proof that a background operation completed.
Keep technical testing and business acceptance connected. Salesforce's user acceptance testing guidance describes testing by end users in a test environment to establish whether the requested outcome is delivered. Its preparation advice includes suitable testers, scenarios, test data and an explicit sign-off process.
Separate acceptance from the whole release decision
A story passing its acceptance checks does not settle every release concern. The team may also need security review, regression tests, integration checks, training, monitoring and a recovery plan. The required depth depends on the change and its consequences.
For example, the onboarding handoff might satisfy its own criteria while a changed field breaks an existing report. That is a reason to test connected behavior, not to pretend the original criterion covered everything.
Use the automation governance guide to connect the business decision with release ownership, testing and recovery. Keep the acceptance owner distinct from whoever has permission to deploy. Technical access does not grant authority to accept a business compromise.
Change the criteria when the decision changes
Requirements can change during delivery. Make the change explicit: record the new decision, revise the affected criteria and examples, assess the impact on work already completed, and identify which tests need to run again.
If delivery no longer requires a start date, do not leave the old requirement in the test script and rely on everyone remembering the meeting. If the accepted quote version becomes mandatory, do not treat it as optional because the original prototype omitted it.
Classify the problem carefully when a test fails. The implementation may be wrong, the expectation may be ambiguous, or the business may be requesting new behavior. Each needs a different decision. Do not rewrite an inconvenient criterion simply to make the current build pass.
Bring one testable slice to the planning meeting
A useful starting record contains the business outcome, user role, starting conditions, action, expected saved result, important exception, acceptance owner and evidence required. Keep it short enough to discuss, but specific enough to expose conflicting interpretations.
Then ask the implementer and business owner to walk through the same example. If either cannot explain what should happen when information is missing or the action is repeated, resolve that decision before making a delivery promise.
If your Salesforce project keeps finishing tickets while missing the intended workflow, discuss the requirements and acceptance gaps with CRM Hacker. The initial conversation is free; detailed assessment and implementation are scoped and priced separately.
About CRM Hacker
CRM Hacker helps teams improve Salesforce, revenue operations and automation. Explore Salesforce, RevOps and AI services for support with requirements, workflow design and implementation, or contact CRM Hacker to discuss the work.