Naming Conventions — Data Sync Pro

This is how we at Data Sync Pro tend to name things — a suggested convention, not a hard rule. Naming comes up most in three places: a Pipeline (the group that holds Executables together), the Executables inside it (the individual rules), and the Variables they read (named, reusable values). Follow as much of this as is useful; a consistent grammar simply tends to make systems easier to read, sort, maintain, and scale. Adapt it to whatever fits your org.

If one idea helps, it's this: names usually read best left → right, general → specific. We join Pipeline and Executable segments with dots in PascalCase — the first segment is the primary object, the last says what the record does. Variables are the one exception we make: a single PascalCase token, no dots, referenced as #Name.

01Pipeline catalog

The Pipeline naming pattern for each surface, with worked examples. A Pipeline is the rules engine that runs its Executables; it typically groups Executables of one surface, and its name then ends in that surface's plural type — Batches, DataLists, Triggers, ActionButtons, DataLoaders — except the org-to-org sync pipeline, whose name leads with DataMigration and drops the surface suffix, since a DataMigration is always a #Batch.

<Object> is a stand-in for the real object or role label — CustomerAccount, PartnerAccount, Opportunity, Quote, and so on. Likewise <Context> and <DataList> are filled in per use.

Pipeline name	Surface	What it does
<Object>.Batches	#Batch	`Opportunity.Batches`, or a custom object `Service_Order_Log__c` → `ServiceOrderLog.Batches` — local Apex batch jobs that run on that object's records.
DataMigration.<SourceOrg>.<TargetOrg>	#Batch	`DataMigration.OrgA.OrgB` — an org-to-org data sync / migration pipeline, run as a batch job. The trailing segments name the source and target orgs (here, from `OrgA` to `OrgB`). The order is a choice: lead with the purpose (`DataMigration.OrgA.OrgB`) or with the direction (`OrgA.OrgB.DataMigration`) — pick one and apply it consistently.
<Object>.Related.DataLists	#Data List	`CustomerAccount.Related.DataLists`, `Opportunity.Related.DataLists`, or a custom object `Service_Order_Log__c` → `ServiceOrderLog.Related.DataLists` — Data Lists that query the objects related to the current record (its related lists), shown on that record's page.
<Object>.DataLists	#Data List	`Product.DataLists` — Data Lists that query the object itself (no `Related` segment).
<Object>.Triggers	#Trigger	`Opportunity.Triggers`, `PartnerAccount.Triggers` — the trigger rules that run on that object's records.
<Object>.ActionButtons	#Action Button	`OpenOpportunity.ActionButtons`, or a custom object `Service_Order_Log__c` → `ServiceOrderLog.ActionButtons` — buttons shown on the object's record page.
<DataListName>.ActionButtons	#Action Button	`Quote.LineItems.ActionButtons` — buttons shown on a Data List; the leading segment(s) are the Data List's name (here, the `Quote.LineItems` Data List Executable), not an object. Naming for Data List Executables is covered separately.
<Object>.DataLoaders	#Data Loader	`Account.DataLoaders`, `ServiceOrderLog.DataLoaders` — the data-load definitions for that object.

02Executable catalog

The Executable naming pattern for each surface, with worked examples. An Executable is a single rule inside a Pipeline, and its surface is set by checkbox fields on the Executable itself that mark which rules engines it runs on — that's what the badge shows. Because those fields already declare the surface — and because the Executable lives under a Pipeline whose own name ends in that surface — its name doesn't need to carry the rules engine's name the way a Pipeline's does (Batches, DataLists, Triggers…); it describes only what the rule does. The closing segment usually mirrors the surface (a plural noun for a Data List, a verb for an Action Button, a behavior for a Trigger; see Purpose by surface).

Executable pattern	Surface	What it does · examples
<SourceObject>.<TargetObject>.<Operation>	#Batch	Local Apex processing — different objects. A batch job that reads a source object and writes a different target object — name both. `ClosedOpportunity.FollowupTask.Insert` reads closed Opportunities and inserts a Followup Task for each.
<Object>.<Job>	#Batch	Local Apex processing — same object. A batch job that reads and writes the same object, so source and target collapse into one segment. `Opportunity.RecalculateForecast`, `Account.BlankUpdate`, `ServiceOrder.PurgeArchived` (the custom object `Service_Order__c` drops its `__c` suffix and reads as `ServiceOrder`).
<SourceOrg>.<TargetOrg>.<SourceObject>.<TargetObject>.<Operation>	#Batch	Cross-org data migration. One hop in an org-to-org sync — the segments name the source org, target org, source object, target object, and operation. `OrgA.OrgB.Account.Account.Upsert` upserts Accounts from OrgA into OrgB.
<Object>.<Collection>	#Data List	Lists a collection of related child records — the closing segment is a plural noun. `Opportunity.Products` lists an opportunity's products; `CustomerAccount.OpenOpportunities` narrows the same idea to a filtered subset (open only).
<Object>.<Relationship>.<Collection>	#Data List	A collection reached through a relationship hop. `Opportunity.PartnerAccount.Contacts` — from the opportunity, hop to its Partner Account, then list that account's Contacts. The middle segment names the lookup you traverse before the final collection.
<Collection>	#Data List	A standalone list with no object prefix. `CustomerAccounts`, `LicenseProducts`, `MyOpenCases`.
<Object>.SelfAdaptive.<Behavior>	#Trigger	Self-Adaptive Trigger — transforms or validates the same record. `Account.SelfAdaptive.Transformation`, `Opportunity.SelfAdaptive.Validation`.
<Object>.[<Event>].<Behavior>	#Trigger	Trigger Action — acts on other records; the `<Event>` segment is optional. `Quote.BeforeInsert.ClosePriorQuotes`, `Quote.Clone.QuoteLineItems.From.Opportunity`.
<Object>.<Verb>	#Action Button	Record Action — a record-level action that ends in a verb phrase. `OpenOpportunity.NewQuote`, `OpenOpportunity.CloseWon`.
<DataList>.<Verb>	#Action Button	Data List Action — an action scoped to a Data List; the leading segment(s) are the Data List's name, not a bare object. `Quote.Products.Edit`, `CustomerAccount.OpenOpportunities.CloseWon`, `CustomerAccount.OpenOpportunities.AddProducts`.
<Object>.<Operation>	#Data Loader	A load definition that brings an external feed into the object — the closing segment names the operation. `Lead.Upsert`.

Examples drawn from a live Data Sync Pro org. Names shown are display Names.

03Variable catalog

A Variable is a named, reusable value that Executables read by reference — written #Name wherever it's used. Unlike Pipelines and Executables, a Variable's name is not dot-delimited: it's a single PascalCase token that reads as a path — the source it draws from, then the value it holds. The # belongs to the reference, not the stored name.

Variable pattern	Kind	What it holds · examples
<Object><Formula>	#Variable	A value computed by a formula — the leading token(s) name the object, the trailing token names the formula. `#OpportunityLineItemSuccessPlanUnitPrice` holds the success-plan unit price on an opportunity line item; `#QuoteLineItemSuccessPlanUnitPrice` is its quote-side counterpart. A boolean formula reads as an `Is…` predicate — `#LineItemProductIsASuccessPlan`.

Examples drawn from a live Data Sync Pro org. The # shown is the reference form; the stored Name omits it.

04Purpose by surface

Each DSP surface expects the closing segment in a different grammatical form. Match the form to the surface and the name tells the reader which engine runs it:

#Data List

Ends in a plural noun naming the collection it returns. No verb.

Opportunity.Products Quote.LineItems CustomerAccount.Orders

#Action Button

Ends in a verb phrase — the action the button performs.

Opportunity.NewQuote Quote.Products.Edit Quote.Email.SendQuote

#Trigger

Ends in a behavior. A Self-Adaptive Trigger transforms or validates the same record; a Trigger Action acts on other records.

Account.SelfAdaptive.Transformation Opportunity.SelfAdaptive.Validation Quote.BeforeInsert.ClosePriorQuotes

Two more surfaces follow the same logic: #Batch jobs name the source and target objects (or an org-to-org hop) plus the operation, and #Data Loader executables end in the load operation. A single Executable can run on more than one surface — the name states intent, the surface flags decide where it runs. #Variable values aren't a surface at all: they drop the dots and read as one PascalCase token — source first, value last (#OpportunityLineItemSuccessPlanUnitPrice).

05What tends to work

None of this is enforced — it's just what we've found reads well. Lean on whatever helps and leave the rest.

Tends to help

Lead with the primary object, in PascalCase joined by dots.
Match the closing segment to the surface — a plural noun for Data Lists, a verb for Action Buttons, a behavior for Triggers.
End a Pipeline in its surface's plural type — Triggers, DataLists, Batches.
Name a Variable source-first, value-last as one token; reference it as #Name.
Keep one label per concept — always CustomerAccount, never sometimes Account.
Pick one order for source → target (or purpose → direction) and apply it everywhere.

Tends to trip people up

Use spaces or underscores — Open Opportunities, close_won.
Repeat the surface inside an Executable — it's already implied by its Pipeline.
Write a Variable value-first — #UnitPriceOpportunityLineItem instead of leading with the object.
Start with the action — CloseWon.Opportunity.
Mix orderings — DataMigration.OrgA.OrgB here, OrgA.OrgB.DataMigration there.
Pile on context the name doesn't need.