Cadence Objects

The cadence objects operate as a family to build a cadence and track the targets' progress through the cadence steps. This section describes how these objects relate to each other.

The objects fall into three categories.

Cadence Builder objects are the building blocks of a cadence.

Cadence runtime objects track active sales targets and their progress through the cadence steps.

CRM data objects are the targets sales managers or reps add to cadences. Targets can be leads, contacts, or person accounts. You can also associate an opportunity with active cadence targets.

Because each cadence is a structure composed of multiple objects, records, and relationships, you can think of it as a graph. The graph represents both the set of records that make up a cadence and the specific relations between those records.

In Cadence Builder, the relationships of the builder objects (the graph) are represented visually. Unless otherwise stated, when we talk about the graph, you can think of the visual graph shown in Cadence Builder.

Next, let’s describe the high-level relationships between Cadence Builder and the runtime objects. The Object Relationships section dives deeper and describes the objects and their relationships at the object field level.

Builder objects are created and modified when you use Cadence Builder. A cadence has one top-level ActionCadence record. The cadence graph is made up of ActionCadenceStep records. The objects that flow from the ActionCadenceStep define the operation of the step.

An ActionCadence record holds basic information, such as the action cadence Name, Description, and the FolderId of the folder that contains it. The ActionCadence record doesn’t define the graph.

An ActionCadenceStep record defines a step within an action cadence. You can determine the action of a step, such as an email or call, by its type. The first step in a cadence has the Root type. The builder generates this step automatically. Subsequent steps in the action cadence are related to each other not through foreign keys but through string fields called StepName and ParentStepName. Each step has a unique name within a cadence and the previous step is referenced by the ParentStepName of the step.

To create an action cadence step that sends an email or makes a call, use the AutoSendAnEmail, SendAnEmail, or MakeACall step type. You can attach a template or have the builder choose a template from step variants defined with ActionCadenceStepVariants records.

After an email or call step, you can create a branch in a cadence. Use branches to take targets through different cadence steps depending on the results of the call or email. Create a branch by inserting a ListenerBranch step after an email step or Branch step after a call step. Branches are defined through rules and rule conditions with ActionCadenceRule and ActionCadenceRuleCondition records.

You can use custom steps to add specific actions other than calls, emails, or LinkedIn steps to an action cadence. To create a custom step, use the CreateTask step type and include instructions for the sales rep in the StepComments field.

To include wait time between action steps, use the Wait step type. Wait steps don’t link to any other objects.

When you’re at the end of the step sequence, the target can exit the action cadence, or you can send the target to another action cadence (daisy-chaining). To link targets to a subsequent action cadence, use the DaisyChain step type and specify the next action cadence in the ChainedCadenceID field.

An action cadence rule can be related to an email or call branch step or a global exit condition. The rule evaluates the related rule condition on an email or call step outcome and determines which branch of the action cadence the target follows when the result is true. The rule condition is made up of a resource, operator, and value. For example, email equals opened.

Use a global exit condition to automatically remove targets from the action cadence before the last step. For example, exit on email hard bounce, exit on email soft bounce, or caller not interested. When a global exit condition evaluates to true, the target exits the cadence immediately.

A step variant allows you to experiment with a single email or call step to test multiple email templates or call scripts to discover which yields better responses. An ActionCadenceStepVariant record has a TemplateId and SplitPercentage. The percentages of all variants associated with a step must add up to 100%. So you can have, for example, 60%, 20%, and 20% of targets going to templates A, B, and C respectively.

At run time, when a target is added to an action cadence, the target is assigned a variant randomly, based on the split percentages. If a target goes through the same action cadence again, the same variant is assigned. This behavior is useful when you want the cadence target to have the same experience, for example, during quarterly check-ins, when looping over multiple action cadences through daisy chains, or when the target is exited from an action cadence and has to be restarted. During run time, an invocable action retrieves the original template ID for the target.

ActionCadenceTracker and ActionCadenceStepTracker track active targets and their action cadence steps. The tracker and step tracker are the runtime versions of a target in an action cadence. They track the status of active targets moving through active action cadences. The history of tracker and step tracker records is stored in the database after the target completes the action cadence.