The Pattern That Breaks Every Growing SaaS Team
There is a workflow that almost every growing B2B SaaS team runs, and almost every one runs it badly: a deal closes, a set of actions needs to happen across multiple systems — CRM, ticketing, legal, and back to CRM — and a human has to review and approve something in the middle. The tools involved are Salesforce, Jira, some form of legal or contract review, a messaging platform for the approval, and Salesforce again at the end to close the loop.
The version of this workflow that exists before anyone has invested in automating it: the AE manually creates a Jira ticket, emails the legal reviewer, pings them in Slack when they don't respond, waits for an email reply approving the contract, manually updates the Salesforce opportunity, and then tells the CS team to start onboarding. This takes four to ten business days and relies on the AE to both initiate the workflow and track it to completion. The moment the AE is busy or traveling, the workflow stalls.
The version with an agentic workflow: the deal closes in Salesforce, the workflow triggers automatically, all downstream steps execute in sequence — with one human review step that routes to the right person with full context and requires one click to complete. End-to-end time drops to one to three business days, and no one has to track it manually. This article walks through how that workflow is actually built, with the design decisions made explicit.
Step 1: Triggering From Salesforce
The trigger for this workflow is a field change in Salesforce: Opportunity Stage moves to "Closed Won." In Salesforce's workflow automation model, this can fire an outbound webhook, call a connected Flow, or update a custom object that a polling integration monitors. The cleanest approach for feeding into a workflow platform is an outbound webhook from a Salesforce Flow: when the trigger condition is met, Salesforce posts the opportunity data — ID, value, customer name, contract terms, associated contacts — to a configured endpoint on the workflow platform.
The field mapping matters here. The fields that the Salesforce trigger sends need to include everything that downstream steps will need: the opportunity ID for writing back to Salesforce at the end, the contract value and terms for the AI extraction and human review steps, the primary contact email for notification, and the deal owner for notifications and escalations. Sending too few fields means downstream steps have to make additional API calls to Salesforce to fetch missing data — which adds latency and failure surface area. Send the full opportunity object at trigger time and let the workflow extract what it needs.
Step 2: AI-Assisted Contract Data Extraction
Before the contract reaches a human reviewer, an AI agent step extracts the structured data that the reviewer will need: contract duration, payment terms, non-standard clauses, data processing obligations, and any exceptions from the company's standard template. This extraction produces a structured JSON output that the human review step will render in the reviewer's task notification.
The practical configuration for this step: the system prompt instructs the model to extract specific fields according to a defined schema, flag any clause where the contract text deviates from a provided standard template, and produce a risk summary with a one-sentence rationale for any flags. The output schema is defined explicitly — the field names and types are fixed — so the downstream human review step can render the output reliably rather than parsing free-form text.
Temperature for this step: 0.1 or lower. This is an extraction task, not a generation task. Consistent, deterministic output is more valuable than creative variation. Running the same contract through the step twice should produce functionally identical output; if it doesn't, the temperature is too high for an extraction task.
Step 3: Creating the Jira Ticket
After the AI extraction completes, the workflow creates a Jira ticket in the appropriate project for the legal or contract review team. The Jira ticket is not the review mechanism — it's the tracking record and the task assignment. The actual review notification goes through the messaging integration. The Jira ticket serves as the source-of-truth for status tracking and as the record that the review team uses to manage their queue.
The Jira action node creates a ticket with: summary field populated from the deal name and contract value, description field containing the AI extraction output formatted as readable bullet points, custom fields mapped to the deal's key attributes (value tier, contract type, review deadline), and an assignee set to the legal team queue rather than an individual — letting the review team's own triage process determine who picks it up.
The ticket ID returned by the Jira API is captured as a workflow variable. Later, when the human review is complete, the workflow updates this Jira ticket with the outcome. This creates the two-way link between Salesforce (source of the deal), Jira (tracking record for the review), and the workflow platform (the execution and audit layer).
Step 4: The Human Review Step
The human review step is the center of the workflow. It routes a task to the assigned reviewer — in this case, a legal team member — and waits for their decision before advancing. The task notification goes to Slack (or Teams) with the full context: deal name, deal value, contract duration, the AI's flagged clauses, and two action buttons: Approve and Request Changes.
The reviewer receives a Slack message that includes everything they need to make the decision: a summary of the deal, the contract's non-standard elements as flagged by the AI extraction step, and the action buttons. For a routine contract at standard terms, the review takes under two minutes. For a contract with multiple non-standard clauses, the reviewer clicks "Request Changes," enters a brief note, and the workflow routes a change request back to the AE through a branch that creates a Jira comment and notifies the AE in Slack.
The SLA for this step is configured at 48 business hours. If the assigned reviewer hasn't acted within that window, the workflow fires an escalation notification to the legal team lead — not a generic reminder to the same reviewer, but a direct escalation that signals urgency. If the team lead also doesn't act within 24 hours, the workflow escalates to the VP of Legal with a summary of the delay.
Step 5: Closing the Loop in Salesforce
Once the legal review is complete — either approved or approved with changes accepted — the workflow executes a Salesforce update action: the opportunity's contract status field is updated to "Contract Approved," the contract terms extracted by the AI step are written to a custom Salesforce object linked to the opportunity, and the deal owner receives a Slack notification that the contract is approved and onboarding can proceed.
The Jira ticket is also updated with the outcome: status changed to "Done," outcome field set to "Approved" or "Approved with Changes," and a comment added with the timestamp and approver name. This gives the legal team's Jira history an accurate record of the contract review outcome that can be referenced for future deals with the same customer.
This closing step is often where the audit trail value becomes most tangible. Six months after this workflow runs for the first time, a compliance question arrives: "Was the Acme contract reviewed before the deal closed? By whom? When?" The answer is available in the workflow audit trail in under 30 seconds: trigger time, AI extraction timestamp, Jira ticket creation time, Slack message delivery time, reviewer action time, Salesforce update time, and the reviewer's name. That answer is not reconstructed from email threads or Slack history — it's a structured record produced automatically by the workflow itself.
We're not claiming this workflow pattern is universal. Deal complexity, team structure, and tool preferences vary significantly. But the underlying architecture — trigger from a state change in the source system, AI pre-processing before human review, human decision with full context delivered in the messaging tool, outcome written back to all connected systems, full audit trail throughout — is a template that applies to a wide range of cross-system business processes. It's a pattern worth building once and adapting, rather than rebuilding from scratch for each new process that fits the same shape.