How to orchestrate Salesforce transaction

Piotr Sałdan
2 days ago
2 min read

What Actually Happens When You Click “Update” in Salesforce?

A sales manager updates an Opportunity.

Seconds later:

The contract value changes
A flow triggers
An approval process updates
Several related opportunities get modified
Quotes are recalculated

Someone asks:

“Why did this happen?”

Silence.

The developer checks:

Triggers
Flows
Process Builder
Apex classes
Validation rules

And after 30 minutes of debugging…

“Oh… it was that trigger.”

If this sounds familiar, you are not alone.

Most Salesforce teams struggle with one simple question:

What actually happens when a record is updated?

The Problem: Invisible Transaction Logic

In many Salesforce implementations, business logic is scattered across:

Apex Triggers
Flows
Approval Processes
Validation Rules
Managed packages

The order of execution becomes difficult to follow. For business teams, it feels like a black box.Troubleshooting becomes slow, confusing, and expensive.

My Solution: Transaction Orchestration

To solve this, I introduced a simple transaction orchestration framework that connects:

Scrum user stories
Business processes
Salesforce execution logic

The goal is simple:

Make system behavior understandable for both developers and business users.

The framework consists of three methods.

Method 1: Name your trigger method after the user story.

Populate Contract Value can have method called -> PopulateContractValue() stored in user story.

Method 2: Draw Orchestration Chart.

It is quite simple. Salesforce Order of execution can be used to help non-technical business people imaging how transaction is being processed

Example of orchestration chart:

Account Update Transaction (Example)

Before Trigger	PopulateContractValue() AdjustApprovalProcess()
Before Flow	Qualify Customer
After Flow	Update Related Opportunities
After Trigger	CalculateRelatedQuotes()

This way things which happen are presented in understandable manner which is readable for non-technical people. My proposal is to name the process and assign a business owner to each of them.

Order of process execution with assigned process owner:

Business Process Name	Process owner	Developer name	Development owner
Populate Contract Value	Josh B.	PopulateContractValue()	Piotr S.
Adjust Approval Process	Josh B.	AdjustApprovalProcess()	Piotr S.
Qualify Customer	Annah B.	Qualify Customer	Johny D.
Update Related Opportunity	Sharon S.	Update Related Opportunities	Johny D.
Calculate Related Quotes	John F.	CalculateRelatedQuotes()	Akash S.

This kind of document brings clarity to business on what happens after what. Assigning developer names to process names simplifies switching orders of execution.

Method 3: Relate user stories to epics treated as business processes:

Business Processes can be tight to epics and user stories related to them. This I could treat as example:

Populate Contract Value	US-1234, US-2544
Adjust Aproval Process	US-3454
Qualify Customer	US-3554, US-5552
Update Related Opportunity	US-2222, US-1123
Calculate Related Quotes	US-5643