A campaign is created when managers are requested to perform access review on their direct reports. It can also refer to a situation whereby role owners are required to review all user accounts having that particular role.
In Welle, role owners are preferred over application owners for access review.
In most customers’ deployments, the majority of campaigns are created for managers. In almost all deployments, there will be requirement to perform access reviews for few critical roles. e.g. finance roles in SAP systems. However, not all roles in an application are required to be reviewed. By assigning to a role owner, this provides greater flexibility.
campaignhas 1 or more
reviewers. A reviewer can be a manager or role owner.
reviewerhas 1 or more
direct reports. An role owner will have everyone that have accesses to the role as his/her direct reports.
direct reporthas 1 or more
access rights. Access rights are commonly known as roles or user roles.
When a reviewer is assigned to a campaign, he/she is said to be assigned tasks, which refers to acting on an access right, i.e. approving, rejecting or reassigning.
A reviewer can reassign a task to another reviewer, when he/she deems another reviewer to be more relevant to review the access right instead. This can refer to cases like secondments or temporary transfers.
The number of times a task is being reassigned can be restricted by administrator. It is recommended not to be more than 1.
A reviewer is expected to complete all tasks before the campaign due date. The campaign due date is defined in weeks by administrator during campaign creation. Reminder emails can be defined and sent to notify reviewers to complete all tasks before due date.
The maximum number of weeks for campaign due date is 12 and can be restricted by administrator. It is recommended not to be more than 4 weeks.
A role owner cannot reassign to another role owner.
A campaign is created in one of the 2 types:
Manual : The campaign remains in this state until the administrator manually triggers the Start Campaign event.
Scheduled : The campaign automatically begins when the current date reaches the scheduled date. A campaign starts right away when
The campaign immediately transitions into
When the campaign is in either of these states, reviewers are unable to perform any action on any task yet as the campaign has been created, but not started.
The campaign transitions into the
In Progress state when the current date and time reaches, or has past the start date.
Marked START on the diagram. It is set in one of 3 ways, depending on which option was selected on the Start Campaign field when campaign was created.
Immediately : (Default) The start date is set to the moment the server receives the campaign creation request. Note that this also implies that a campaign created with this option selected immediately transitions to the
Manually : The start date will not be set until the administrator manually starts the campaign.
In the future (scheduled) : The start date is set to the date indicated in the Start Campaign Date field.
In this state, the latest snapshot of a campaign is taken - Users, Roles and Reviewers. The tasks are then assigned to the reviewers based on the rule(s) specified.
Reviewers are expected to take actions on their tasks before the due date (the number of weeks defined in the Duration field during creation after the Start Date).
These actions include the following:
Approve : The user who owns the task(s) is allowed to retain the given role.
Reject : The user who owns the task(s) is not allowed to retain the given role.
Reassign : The decision as to whether or not to retain the given role will be passed on to a selected reviewer.
When all the tasks under a reviewer for a given campaign have been taken action on, the reviewer will now be able to sign off his/her portion of the campaign. This marks all the tasks currently assigned to the reviewer as
Signed, locking the tasks and preventing any further action from being taken on the tasks.
If all tasks under a reviewer are signed, the reviewer’s status for the campaign is marked as
Similar to how reviewers are marked
Completed, a campaign’s status is marked
Completedwhen all reviewers have the
Completedstatus. This also implies that all the tasks in the campaign have been signed.
Once the due date is over, the campaign enters the
Overdue state. The due date being [campaign duration] days after the campaign’s start date.
In this state, reviewers can still perform action and sign-off tasks before the campaign transitions into the
When the campaign’s auto-close field is
true (which is the default), the campaign’s end date is set to the same date as the campaign’s due date, effectively allowing campaigns to transit from
In Progress or
Completed state into
Campaign enters the
Closed state after the current date is, or has past the End Date.
The End Date field can be set in one of 2 ways:
the campaign’s end date field is
automaticallyset to the campaign’s due date if the campaign’s auto-close field is true, or
the campaign’s administrator can
manually stopthe campaign
In this state, reviewers can no longer perform any action on any task in the campaign, regardless of whether or not they have signed off.
Campaigns that enter this state remain in this state until they are deleted. It is not possible to change the state of a campaign that has reached
Asynchronous Campaign Creation¶
When a campaign is created, a snapshot of the
access rights of every
direct report at that point of time is taken. A
reviewer performs access review based on that snapshot.
The process of taking a snapshot takes time. In the backend, tasks are copied from IDM database to Attestation database.
This can potentially cause the front-end to be non-responsive.
In Welle, asynchronous campaign creation is implemented.
As soon as the IAM administrator creates the campaign, the front-end will display a message informing the campaign will be created asynchronously.
When the campaign is finally created in the backend, an email notification will be sent to the IAM administrator.
A campaign can be created for 2 types of reviewer type:
Manager. This type is most common. Campaign will be reviewed by managers, who will evaluate the access rights of their direct reports.
Role Owner. This type allows a campaign to be reviewed at Role-level, instead of Application-level, giving better flexibility.
In some applications, there might be more than 1 owner. Each owner is responsible for some
In such situation, a campaign created for
Role Owner review makes sense.
An administrator creates a
mapping from Welle to a LDAP server.
The administrator creates 2
access rights - one for managers and one for all other users.
The administrator then creates 2 corresponding
As the role for Advance Group is sensitive, the administrator assigns this role to a manager from the LDAP team, instead of a normal LDAP administrator.
A scope filter defines the scope of a campaign.
A campaign can be created for:
1 or more
applications. This type of campaign is known as Application-level Access Review. Reviewers are usually role owners.
user. This type of campaign is usually created for
Leaver. Reviewers are usually managers.
department. This type of campaign is known as Department-level Access Review. Reviewers are usually managers.
A campaign can be configured to:
automatically close when all access reviews within the campaign are signed by reviewers; and/or
automatically close when campaign ends
A remediation is an action taken after a reviewer
rejects an access right.
A campaign can be configured to:
manually remediates; or
automatically remediates upon campaign signed; or
automatically remediates upon campaign closure
Read Campaign Status - Created for more information.
Read Configuration - Governance - Email Templates for more information.
The templates are duplicated from
Configuration - Governance - Email Templates. Each campaign is allowed to further customize each email template.