A sales workflow implementation is complete only when one defined trigger can move through evidence, identity, decision, action, verification, and recovery without losing ownership. Configuration is one step. The release also needs authority, data contracts, failure tests, reconciliation, pilot gates, rollback, and an operating owner.
Define the workflow boundary
Start with one observable entry condition and one business decision. “Automate sales” cannot be implemented or tested. A usable boundary looks like: “When a completed customer-approved meeting is attached to an eligible opportunity, propose a follow-up task and CRM note for the opportunity owner to review.”
Freeze eligible records, excluded records, trigger, evidence, identity rule, decision owner, permitted outputs, write destinations, stop conditions, retention, metrics, and rollback. State what the workflow cannot do.
Map current state and authority
Document the manual workflow before redesigning it. For every handoff, record who acts, which system they trust, what they copy, what they decide, what can block them, and how downstream state is checked.
| Authority | Owner | Implementation question |
|---|---|---|
| Read | System/data owner | Which tenants, objects, records, and fields? |
| Propose | Workflow | What schema and evidence are mandatory? |
| Approve | Named rep or manager | Can they edit, reject, and see uncertainty? |
| Write or send | Scoped integration | Which side effects, retries, and limits? |
| Override or roll back | Operations owner | How is current state restored and audited? |
Write data and action contracts
Write a contract for each boundary between systems. Include source ID, event ID, observed time, account/contact/opportunity IDs, tenant, owner, field versions, evidence, purpose, expiry, dedupe key, proposal schema, reviewer decision, write target, before/after values, acknowledgment, and actual state.
Salesforce documents upsert using an external ID to insert or update depending on whether a matching record exists. That is a mechanism, not a safety guarantee. Stable ID ownership, authorization, version conflicts, idempotency, and post-write verification still belong in the contract.
Configure the happy path
Configure the smallest end-to-end happy path in a sandbox or read-only mode first. Use allowlists, least privilege, field validation, preview, no-op mode, bounded retries, and a kill switch. Preserve model, prompt, rule, mapping, and policy versions where AI is involved.
The Gangly Workflow Sequencer can be evaluated for a reviewed signal-to-follow-through path. Repository facts require rep review before outbound sends or CRM sync. Confirm live integrations, fields, permissions, and failure behavior in the buyer’s own environment.
Test failures before launch
Failure tests are release requirements. The OWASP API Security Top 10 highlights object/property/function authorization, sensitive business flows, inventory, and unsafe third-party API consumption.
- Replay and reorder events; send the same event twice.
- Revoke credentials and deprovision the owner mid-run.
- Merge, delete, or reassign the target record before the write.
- Return timeout before and after downstream acknowledgment.
- Change a field schema, rate-limit the connector, and interrupt logging.
- Place hostile instructions in retrieved email, CRM, or web content.
Run a bounded pilot
Release by risk tier: read-only, draft-only, then a small canary for approved low-risk writes. Freeze population, versions, observation window, comparison process, reviewers, and hard gates. NIST describes its AI RMF as voluntary risk-management guidance; use it to structure local evaluation rather than claim certification.
Measure eligible triggers, valid proposals, abstentions, reviewer edits, accepted actions, wrong-record associations, duplicates, permission blocks, latency, unresolved runs, rollback success, and operator time. Adoption is meaningful only after quality and safety pass.
Reconcile and decide
Every run must end in an explained state. Reconcile with three equations:
- Accepted triggers = policy rejects + duplicates/expired + proposals + unresolved trigger errors.
- Proposals = rejected + canceled + action attempts + unresolved decisions.
- Action attempts = acknowledged once + confirmed failed + unresolved write state.
Any unexplained remainder blocks expansion. The release decision must name passed and failed gates, incidents, current limitations, owners, rollback status, manual path, export result, and next review date.
Printable implementation checklist
☐ One trigger, population, decision, and action
☐ Current-state map and system of record
☐ Read, propose, approve, write, send, delete, and override owners
☐ Source, identity, evidence, expiry, and dedupe contract
☐ Field allowlist, before/after state, and idempotency
☐ Sandbox, preview, canary, kill switch, and manual path
☐ Golden cases, hostile inputs, outages, replay, and schema changes
☐ Raw quality, safety, adoption, and labor counts
☐ Full reconciliation and tested rollback
☐ Export, disconnect, deletion, incident, and change owners
Implement one bounded path until it is boring, observable, and recoverable. Then expand through a new reviewed contract—not by quietly granting the first workflow more authority.