Sending a Deployment for Approval

Some users may not have permission to approve their own deployments. Instead of an Activate button, these users will encounter a Send for Approval button. A user with approval rights must approve the communication in order for it to execute.

You will also be able to select one or more ‘Approval Teams’ for each deployment.

For a deployment sent for approval to an ‘Approval Team’, when it is approved by any team member, that action is deemed to be taken on behalf of the ‘Approval Team’. i.e. other members of the Approval Team cannot change that decision later.
You can send your deployment to be approved by one or more ‘Approval Teams’ as well as by ‘Specific Individual Approvers’.
If an individual X is a designated approver and is also part of an approval team T1, then X will not need to approve the deployment twice; when X approves the deployment, it will be considered as ‘approved’ in their individual capacity and also on behalf of T1.
If another member of T1, say Y, has approved the deployment on behalf of team T1, then X will still need to approve the deployment in their individual capacity.

Approval Management Screen:
You can also view a list of deployments which are in ‘approved’ / ‘rejected’ / ‘approval pending’ status on the ‘Approval Management’ screen (Campaign Management > Campaign > Approval Management).

How to assign a user to an ‘Approval Team’:
A user can be assigned to an ‘Approval Team’ on the ‘Create / Update user’ screens. A single user can be assigned to a maximum of four ‘Approval Teams’.

Specifically Approve Each Occurrence of a Recurring Deployment
You can seek approval for each specific occurrence of a ‘Recurring Deployment’. This will be an optional configuration available while selecting approvers.

As soon as an occurrence (Run #) of deployment is ‘Completed-by-Time’ or ‘Completed-by-Base’, then the approval cycle will begin for the subsequent Run #.
After a few initial occurrences of deployment have been approved without any concerns from the approver(s), and if further occurrences do not need to be explicitly approved, then you can pause the deployment; deselect this checkbox and resume the deployment again. In this case, the next occurrence of the deployment will be sent for approval one last time (in case the deployment creator has made any other changes to the content while it was paused) and after that occurrence has been approved, then subsequent occurrences will not be sent for approval anymore.
If an occurrence is rejected, then the Target Group preparation will start again once the deployment is amended and approved. In case the TG source is FTP, the data file will need to be resupplied.
The ‘Approval Log’ shown on the Summary screen will get reset for each Run #.
o Approval Log is visible to all users within the User Group.
o Approval Log will show each individual and team-based approval for every approval cycle.

Approval Log for One-time Deployments:

In the below example screenshot, the deployment schedule for the one-time deployment is shown above the approval log.
Initially (for ‘Approval Cycle’ #1) there’s only one designated approver (‘rachitasqa1’).
This approver rejected the deployment and sent it back to the deployment creator with a comment.
For Approval Cycle #2, there are two designated approvers and at the time this screenshot was taken, both of those approvers have not yet reviewed the deployment. Both of them must approve before this deployment can become activated.

Approval Log for Recurring Deployments involving Team-based Approvals:

The Approval Log will reset for each occurrence (Run #). i.e. the Approval Log will only show approval cycles for a single occurrence of a recurring deployment.
In the below example screenshot, the Approval Log corresponding to the very first occurrence (Run #1) of a Recurring Deployment is shown. The corresponding Deployment-Schedule for Run#1 is also shown above the Approval Log.
Initially (for ‘Approval Cycle’ #1), the following approvers have been designated :
o Approver Team ‘teama’ (which has two team members named ‘rachitasharma99’ and ‘rachitasqa1’).
o Approver Team ‘teamb’ (which has two team members named ‘R_0504’ and ‘rachitasharma99’). Note that it is possible for the same approver to be part of two Approval Teams.
o Individual approver ‘rachitasqa1’.
The approver ‘rachitasqa1’ has rejected the deployment.
In the Approval Log, there are two entries for this rejection: one for the rejection by ‘rachitasqa1’ in their individual capacity and another entry indicating that this means the deployment has also received a rejection on behalf of the Approval Team ‘teama’.
Now the deployment has been sent back to the deployment creator to make amends as per the comments.
For the Approval Cycle #2, the deployment-creator has then designated only one approver: ‘teama’. No individual approvers have been designated.
This time around, the team member ‘rachitasharma99’ has approved the deployment on behalf of the Approval Team ‘teama’.
Now that the deployment has secured the necessary approvals, it will be activated.