This feature is controlled by a separate license. If you need it, contact your customer success manager.
Overview
Some operations should not take effect immediately—for example, creating a Campaign or changing the permission scope of an account. Instead, they must be approved by one or more parties before taking effect. The Approval Center supports this process. You can configure approval flows based on your organization’s internal process requirements, ensuring that these operations are performed only after the relevant stakeholders approve them.
Entry
Upper-right corner of the navigation bar > Approval Center
Terminology
| Term | Description | Example |
|---|---|---|
| Approval subject | The type of business operation that requires approval | Journey, Campaign, Placements, Account Management, Role Management, Traits, and so on |
| Approval switch | The projects in which this type of business operation requires approval | Campaigns require approval in the production project but not in the test project. |
| Approval flow | The approval process: who approves and in what order | A Campaign approval flow contains two approval nodes: Account A approves first, followed by Account B. |
| Initiator | Who triggers the approval flow when performing an operation | Operations initiated by all accounts require approval. |
| Approver | Who performs the approval | Approvers can be configured by account, role, position, or another dimension. |
| Approval work order | A specific approval request | Alex requests to modify Campaign A; work order ID: 1024. |
| Or-sign | The approval node passes when any one person approves. | If either Account A or Account B approves, the current approval node passes. |
| Countersign | The approval node passes only when all child nodes approve. | The current approval node passes only after both Account A and Account B approve. |
| To-Do / Processed / Initiated | Waiting for my approval / processed by me / submitted by me | Everyone can open these three lists, but their contents are permission-controlled. |
Conditional-branch terminology (introduced in SA 305):
| Term | Description |
|---|---|
| Conditional branch | Routes requests to different approvers based on conditions within the same approval flow. For example, when a Campaign's channel instance is Channel 1, Account 1 must approve; when it is Channel 2, Account 2 must approve. |
| Match rule | Determines what happens when one request matches multiple branches. Two options are available: First match (default; enters the first matching branch from left to right) and All matches (all matching branches are approved in parallel). |
| Otherwise | The fallback branch used when no condition is met. It is generated automatically by the system and cannot be deleted. |
Quick Start
This section explains how to configure an approval flow.
Step 1: Turn on the approval switch
Go to Approval Center > Left navigation > Approval Switch, locate the applicable approval subject and project, and turn on the switch.
When the approval switch is off, newly initiated operations do not go through approval. Turning it off does not affect in-progress approval work orders.
Step 2: Create an approval flow
Go to Left navigation > Approval Configuration, click Create Approval Flow, and select a creation method:
-
Custom Approval Flow (default): You define all approval nodes. Select this option in most cases.
-
Integrate with an Existing Approval Flow: Connect an external approval system that is already in use. This requires assistance from the Sensors Data customization team. For details, see .
Click Confirm and Create to open the configuration page.
Step 3: Configure basic information on the left side of the page
The basic settings are on the left, and the approval flow canvas is on the right.
| Setting | Description |
|---|---|
| Approval flow name | Enter a name as needed. |
| Applicable project | Only one project can be selected. It determines which parameters are available in subsequent nodes. We recommend configuring the left side before the right side. |
Step 4: Configure the initiation node (who can submit the request)
Click the initiation node on the canvas and configure the following settings:
| Setting | Description |
|---|---|
| Approval subject | Select a registered business object, such as Journey (New). The selected subject determines the type of business operation managed by this approval flow. |
| Initiator | First select an initiator dimension (single select): account, role, or position. Dynamic attributes integrated by the customer, such as organization, are also supported. Then select one or more specific objects under that dimension. To allow anyone to initiate the flow, select Unlimited. |
After you submit the settings, the initiation information is displayed on the initiation node.
Step 5: Configure approval nodes (who approves)
Click an approval node on the canvas and configure the following settings:
| Setting | Description |
|---|---|
| Node name | Enter a name as needed. |
| Approver | First select an approval dimension—account, role, position, or a dynamic attribute such as organization—and then select one or more specific objects. |
| Approval node settings | Options: Cannot approve requests initiated by oneself and Approval comments are required when rejecting or returning a request. |
| Timeout reminder (days) | Specifies how many days may pass before reminders begin. If left empty, the node never times out. |
| Approval notification method | Message Center (default) or email notification (introduced in SA 305). |
There is no limit to the number of approval node levels. Add nodes as required by your use case. Before saving, make sure an approver has been selected for every node.
Step 6: Save and enable
Save the completed configuration. New approval flows are Enabled by default. If a flow is disabled, enable it from the list—disabled approval flows do not take effect.
Step 7: Verify
Use an account included in the initiator scope to trigger an operation that requires approval in the relevant business feature—for example, create and save a Campaign. Check whether the approval submission page appears and whether the work order appears in the appropriate approver's To-Do list.
Advanced Configuration
Or-sign / Countersign
-
Or-sign: The node passes when any one person in the node approves.
-
Countersign: The node passes only when all child nodes approve. If any child node is rejected or returned, the entire approval flow ends immediately. Unprocessed child nodes stop progressing and no new To-Do items are generated for them.
After configuration, or-sign and countersign nodes use different styles on the canvas.
Conditional branches: route different cases to different approvers
Conditional branches were introduced in SA 305.
By default, an approval flow follows a fixed path. Conditional branches route requests according to their content. For example, if a Campaign's reach channel instance contains 1, Account 1 approves; if it contains 2, Account 2 approves; all other requests are approved by the admin.
Approval subjects that support conditional branches
| Approval subject | Supported condition fields |
|---|---|
| Journey (New) | Reach content type, channel instance, Journey group, entry type, associated scenario, and feature used |
| Campaign | Reach content type, channel instance, Campaign group, Campaign type, associated scenario, and feature used |
| Feed Placement / Pop-Up Placement | Associated scenario, placement, and placement group |
| Carousel Placement | Associated scenario and placement |
Add a conditional branch
Click + in the approval flow configuration and select Add Conditional Branch. The system automatically generates:
-
A configurable branch named Condition 1 by default, which can be renamed.
-
An Otherwise fallback branch that cannot be deleted.
-
An approval node under each branch.
Configure conditions
Select a branch line other than Otherwise, and configure the following settings in the drawer on the right:
| Setting | Description |
|---|---|
| Title | Condition N by default; editable. |
| Condition field | Available fields depend on the approval subject. |
| Operator | Equals, does not equal, contains, or does not contain. |
| Value | Select one or more values based on the field type. Values come from actual data, such as a specific Journey group or channel instance. |
| Priority | Determined automatically by the left-to-right branch order. |
Each branch supports up to five conditions, connected using AND or OR.
Conditional-branch match rules
Click the Edit Match Rule icon to the right of Add Conditional Branch and select one option:
| Match rule | Execution logic |
|---|---|
| First matching branch from left to right (default) | Enters the first matching branch and stops evaluating subsequent branches. |
| All matching branches | Enters all matching branches for parallel approval. The flow continues only after all entered branches approve. |
| Parallel-branch scenario | Flow rule | Final work order status |
|---|---|---|
| All entered branches approve | The branches converge and the flow moves to the next node; without one, the flow ends. | In Approval / Approved |
| A node in any branch rejects | The flow ends immediately. | Rejected |
| A node in any branch returns | The flow ends immediately. | Returned |
| Some branches have approved and others are still in approval | The flow waits at the convergence point. | In Approval |
If no condition is met, the flow enters the Otherwise branch.
Notes:
-
Only one conditional-branch node can be added to an approval flow. Only approval nodes can be added before or after it.
-
Only one approval subject can be selected when adding a conditional branch.
-
When you switch the approval subject, the system warns that the conditional branch will become invalid. After confirmation and a successful save, the branch and its approval nodes are deleted automatically.
-
Deleting a conditional branch deletes the entire branch line. If you delete only an approval node, at least one must remain under the branch.
-
The flow cannot be saved if any setting is empty, the flow has no approval nodes, or a conditional branch has no approval nodes.
Approval Notifications
Notifications are delivered through Message Center or email. Email notifications were introduced in SA 305.
| Trigger | Recipient | Method |
|---|---|---|
| New To-Do data | All approvers at the current node | Message Center / Email |
| Approval timeout | All approvers at the current node | Message Center / Email |
| Work order reaches a final status | Initiator | Message Center / Email |
| Flow exception: empty initiator, approver, or project | Last person who updated the flow; admin if the account does not exist | Message Center |
The first three triggers are controlled by the node's Approval notification method. Flow-exception notifications are sent automatically.
Integrating with an External Approval Flow
This option connects an external approval system already in use. Settings include approval flow name, applicable project, approval subject, initiator, and existing approval flow, which must be provided through an API or another integration method.
For details, see .
-
Integration requires a technical assessment and incurs additional development costs because the customization team must be involved. Contact your customer success manager.
-
External-flow work orders do not appear in the To-Do or Processed lists.
-
Approval logs show only the external node's overall status, not intermediate states inside the external system.
Processing Approval Data
To-Do
To-Do contains data that currently requires my approval. Visible data must meet both conditions:
-
I have permission for the approval subject.
-
I am included in the current approval node.
Users can switch among projects in which they have permission for at least one approval subject.
Lists and filters
System-defined fields: Work order ID, initiator (name + account), initiation type, approval flow (ID + name), approval initiation time, previous approval time, and initiating project. Fields registered for the approval subject are also displayed. For example, Campaign fields include Campaign ID, name, start and end time, and type.
Default sorting: Timed-out work orders appear first and are sorted from longest to shortest timeout duration. Other work orders are sorted by approval initiation time in descending order. Manual sorting applies the selected rule to all data.
Left navigation: Data is grouped by approval subject with record counts. The first subject is selected by default.
Filters: Fuzzy search supports work order ID, initiator, initiation type, approval flow, and registered fields. Approval initiation time and latest approval time support search and sorting. Initiating project supports filtering.
Details page
Click Approve to open the details page:
| Section | Content |
|---|---|
| Approval Content | Basic information and a before-and-after comparison, with single/split view and zooming |
| Request Notes | Notes entered by the initiator |
| Related Attachments | Files uploaded by the initiator; up to 5 MB each. Supported formats include xls, xlsx, zip, txt, and csv. Other formats can be archived before upload. |
| Approval Log | Approvers, approval times, and statuses for all nodes |
Approval actions
| Action | Meaning | Can the initiator modify and resubmit? |
|---|---|---|
| Approve | The request is approved and the data takes effect. | — |
| Reject | The request is invalidated. | No; a new request is required. |
| Return | The request does not pass, but the original can be modified and resubmitted. | Yes. |
-
Available buttons depend on the actions registered for the approval subject. Approve is always available; at least one of Reject and Return is registered.
-
If data has a resource validity period, expired data cannot be approved and can only be rejected or returned.
-
If no validity period is specified or the data has not expired, a confirmation dialog appears before approval takes effect.
-
Whether comments are required for Reject or Return depends on the node configuration.
Processed and Initiated
Processed contains data I have processed. Users can switch projects. Compared with To-Do, it adds Approval Processing Time and Approval Action (Approve / Reject / Return). Records are sorted by approval initiation time in descending order by default. The details page does not allow further actions.
Initiated contains requests I submitted. One project is displayed at a time. Use the project switcher or search next to the title. Compared with To-Do, it adds Approval Flow Source, Latest Approver, and Approval Status.
Withdraw: Available when the approval subject supports withdrawal and the status allows it. After confirmation, the status becomes Withdrawn, a final status. To continue, initiate a new request.
Approval Data Management
This feature lets administrators view approval data for all approval subjects for management and auditing. One project is displayed at a time; users can switch among projects for which they have Manage Approval Data permission.
List fields: Work order ID, initiator, approval subject, initiation type, initiating project, approval flow, creation method, initiation time, previous approval time, latest approver, and approval status.
Query criteria: Work order ID, initiator, initiation type, approval flow name/ID, and latest approver support fuzzy search. Approval subject, initiating project, and status support multi-select filtering. Creation method is single-select. Both time fields support range queries.
Operations: Export query results, export logs for selected records, and view details.
Approval Log
The log shows the nodes through which an approval actually progressed, its progress, and its final result.
Initiation node: Always displays Initiated, the initiator's name (account), and initiation time.
| Standard-node stage | Displayed content |
|---|---|
| Before approval | Status (Not Started / In Approval), node name, and all eligible approvers |
| After approval | Status, node name, actual approver name (account), time, organization if available, and comments if entered |
Countersign node: Displays all child nodes and is always named Approval Node (Countersign). Processed child nodes appear first, sorted by processing time. If any child node is rejected or returned, the flow ends and unprocessed child nodes are no longer displayed.
After the flow ends:
-
All approved: complete path + flow end node.
-
Any rejection/return: path through that node + flow end node.
External approval flow: Shows only the external node's overall status, external approval order number if available, final result, and completion time—not intermediate external-system states.
Permissions
| Menu | Permission | Description |
|---|---|---|
| Approval Switch | View Approval Switch / Enable or Disable | Controls viewing and editing respectively. |
| Approval Flow Configuration | View / Add / Edit / Delete / Copy / Enable or Disable | Each operation is controlled independently. |
| Global Approval Settings | Global Approval Settings | Configures global approval-node settings. |
| Manage Approval Data | Manage Approval Data | Data scope: requests initiated by everyone, or only by the current user. |
| Approval Subject Permissions | Approve Account Management / Role Management / Authorization Subjects / Campaigns / Journeys / Journey New / Carousel Placements / Feed Placements / Pop-Up Placements | Determines which business work orders the user can approve; registered by the product line. |
Approval subject permissions are associated with both the Approval Center license and the product-line license using an AND relationship. The permission and approval entry appear only if the customer has both licenses.
FAQ and Troubleshooting
Q1: Why is approval not triggered after I configure the flow?
-
Check whether the approval switch is on.
-
Check whether the applicable project matches the current project.
-
Check whether the current account is in the initiator scope.
-
Check whether the flow is Enabled.
Q2: Why is “Add Conditional Branch” unavailable under “+”?
Possible causes: no approval subject is selected; multiple subjects are selected; the subject does not support branches (legacy Journey does not, but Journey New does); or the flow already contains a conditional branch.
Q3: Why am I not receiving approval emails?
Check whether Email Notification is selected on the node and whether a platform or project mailbox is configured.
Q4: Why is there no approval icon at the top?
An approval license must be configured and the approval feature must be installed. Contact your platform administrator.
Q5: Why is a work order missing from my To-Do list?
Check whether you have permission for its approval subject, whether it is at a node requiring your approval, and whether Cannot approve requests initiated by oneself is selected when you initiated the request.
Q6: Why did in-progress work orders disappear after I edited or deleted the flow?
This is expected. Editing, deleting, or disabling a flow causes in-progress work orders to be rejected or returned by the system.
Q7: Can I modify a returned work order?
Yes. A returned work order can be modified and resubmitted. A rejected one is invalid and requires a new request.
Q8: Can I modify a withdrawn work order?
No. Withdrawn is final. Initiate a new request if needed.
Q9: Why do some work orders never time out?
Their approval nodes have no configured timeout reminder period. Such nodes never time out.
Product Features Integrated with Approval
| Integrated feature | Supports conditional branches |
|---|---|
| Journey | No |
| Journey New and Campaign | Yes |
| Placements (Feed / Carousel / Pop-Up) | Yes |
| Account Management, Role Management, and Authorization Subjects | No |
| Trait | No |
| A/B | No |
Source: