Delegation and escalation
About delegation
Bravura Security Fabric users can act on behalf of other users in one of two ways:
A user’s responsibilities can be delegated to another user.
By failing to act on a workflow request in a timely manner, the request can be escalated to another user.
A user who initially holds a responsibility is known as the primary . A user who acts on behalf of another is known as a delegate . Delegations can be indefinite or for a limited time, and can be canceled at any time. Any user can become a delegate. Both the primary and the delegate must have an email address configured in Bravura Security Fabric .
Users with the ”Delegate workflow requests” permission are known as delegation managers . These users can delegate another user’s responsibilities. They can also use API Service requests (DelegationCancel and DelegationList) to clean obsolete delegations. To send these API Service requests, a delegation manager also needs the "IDAPI caller" privilege. For details on the DelegationCancel and DelegationList requests, see the api.pdf.
Any user can request that all of their own responsibilities be delegated. They can also delegate responsibilities for a single request. The recipient of the request for delegation follows a link in their email invitation or uses an option on the main menu to respond.
When a delegate accepts a request for delegation, they are given the same permissions as the primary. For example, if the primary can access reports, this right will be passed on to the delegate. When a delegation ends or is canceled, those options are no longer available to the delegate.
Note
Network resource ownership managed by Bravura Security Fabric is not delegable.
In some cases, a delegate authorizer may have to review a request sent to them for approval more than once; as themselves and then as another primary, or if they have accepted multiple delegation requests. The delegate can choose who they are acting as when they review a request for approval. This is necessary because users may have different access to attributes. For example, using the figure below, if Carl Wong is a delegate for Sylvia Granger and Dan Singh, and a request is made that requires the approval of both authorizers, then Carl Wong (as their delegate) must review and approve the request; first as Sylvia Granger, then again as Dan Singh, before it will be considered authorized.
Users may be allowed to delegate responsibilities that have in turn been delegated or escalated to them. This is referred to as sub-delegation . It is controlled by the user requesting the delegation, or by a plugin.
Configuring a delegation plugin
You can use a plugin to determine:
To whom primaries can delegate
Whether they should be able to sub-delegate by default
Whether they should be able to override the sub-delegation default
The default delegation timeout for no response
A minimum and maximum delegation timeout that they can request
The default action to perform upon a timeout
The actions they can specify to be performed upon a timeout (accept, reject, escalate)
The default plugin is delegation-default.psl. You can modify delegation-default.psl to customize it for your environment. Rename the plugin so that it cannot be overwritten during a Bravura Security Fabric upgrade. Alternatively, you can copy the sample plugin-delegation.psl from the <instance>\samples\ directory to the <instance>\plugin\ directory and modify it for your environment.
The delegation options plugin must be listed in the DELEGATION OPTIONS PLUGIN field in the Workflow > Options > Delegation menu.
Requirements
It is recommended that the plugin be written in PSLang, which has functions to automatically deal with the input and output protocol (KVGroups). The plugin must be placed in the \<instance>\plugin\ directory.
See Writing plugins for general requirements.
Execution points
This plugin is run by the View and update profile (IDR) module and Requests app.
Input
The input to this plugin consists of:
"" "" = {
"primary" "<primary's ID>" = {
"id" = "<primary ID>" # The user who is having their authorizations delegated
"name" = "<primary's full name>"
"account" "" = { ... }
# Present when PLUGIN DATA USER ATTRIBUTE DETAILS enabled
# See Optional user attribute, account and role detail KVGroups.
"attribute" "<attribute ID>" = { ... }
# Present when PLUGIN DATA USER ACCOUNT DETAILS enabled
# See Optional user attribute, account and role detail KVGroups.
}
"defaultAct" = "A" # Default action to take at timeout (from the CGI)
"endDate" = "2147410800" # Specified end date (from the CGI)
"needAccept" = "F" # Must accept (from the CGI)
"responseTime" = "1122825420" # Timeout (from the CGI)
"subDelegable" = "F" # Sub delegate (from the CGI)
"delegate" "<delegate's ID>" = {
"id" = "<delegate's ID>" # The user specified as the delegate (from CGI)
"name" = "<delegate's full name>"
"account" "" = { ... }
# Present when PLUGIN DATA USER ATTRIBUTE DETAILS is enabled
# See Optional user attribute, account and role detail KVGroups.
"attribute" "<attribute ID>" = { ... }
# Present when PLUGIN DATA USER ACCOUNT DETAILS is enabled
# See Optional user attribute, account and role detail KVGroups.
# Note that this KVGroup will only be present after the primary
# has entered a delegate.
}
} Output
The output of this plugin should consist of:
"" "" = {
"errmsg" = "<error message>"
"retval" = "<number>" # 0 is success, anything else failure
"delegates" "" = {
"allUsers" = "true|false" # true means the primary can delegate
# to any user. False will restrict the
# list to the ones specified... Lack
# of this key will be interpreted as
# "false".
"delegate" = "<a user to whom the primary can delegate>" ⋆
"validdelegate" = "true|false" # False means that the chosen delegate
# is not valid; the text will be
# cleared from the 'Delegate' field
# on the 'Delegation information' page.
}
"subDelegation" "" = {
"enabled" = "true|false" # enable sub-delegation when they come
# to the page initially
"modifiable" = "true|false" # allow/disallow the primary to enable
# or disable sub-delegation
}
"timeouts" "" = {
"enabled" = "true|false" # enable/disable timeout of
# delegation requests when the
# primary initially comes to the page
"modifiable" = "true|false" # allow/disallow the primary to
# enable or disable timeouts
# If the proposed delegate does not respond to the delegation
# request in a given amount of time, 3 actions can be taken.
# accept -> The delegation is automatically accepted
# reject -> The delegation is automatically rejected
# escalate -> The delegation is escalated
"allowableAction" = "accept|reject|escalate" ⋆ # a list of actions
# that are allowable
"action" = "accept|reject|escalate" # the action that will be
# initially selected
"timeout" = "<seconds since the epoch>" # Number of minutes that must elapse
# before the action is taken
"timeoutMin" = "<seconds since the epoch>" # The user will not be able to
# specify a timeout less than this.
"timeoutMax" = "<seconds since the epoch>" # The user will not be able to
# specify a timeout greater than this.
}
"times" "" = {
"startDate" = "<seconds since the epoch>" # Initially filled in
# delegation begin time.
"startDateMin" = "<seconds since the epoch>" # Primary cannot specify
# a value less than this
"startDateMax" = "<seconds since the epoch>" # Primary cannot specify
# a value greater than this
"endDate" = "<seconds since the epoch>" # Initially filled in
# delegation end time.
"endDateMin" = "<seconds since the epoch>" # Primary cannot specify
# a value less than this
"endDateMax" = "<seconds since the epoch>" # Primary cannot specify
# a value greater than this
"defaultEndDate" = "<seconds since the epoch>" # Return a default end
# date which will be used
# by the GUI if endDate
# returned by the plugin is 0.
}
} About escalation
If an assigned authorizer does not respond to a request in time, Bravura Security Fabric can escalate the request to other authorizers. An authorizer who initially holds a responsibility is known as the primary . An authorizer who acts on behalf of another is known as a delegate.
Bravura Security Fabric includes a built-in program, escorgchart.pss , that uses the authorizer’s calculated level in the OrgChart to escalate a request to the next authorizer in the reporting chain. See Implementing organization chart management for information about importing OrgChart data. You can also write a custom plugin to escalate requests using other sources.
Bravura Security Fabric can also utilize user classes to determine how to escalate a request. You can configure user classes instead of, or in conjunction with, an escalation plugin. If both are used, the user class point runs first, and passes a short-list of delegates to the plugin, which determines the final delegates to return. See more information on using user classes with these plugin points .
Following is an example of how an escalation might proceed using the escorgchart.pss plugin, based on the figure below:
Marc LeBlanc submits a request that requires authorization from Kathy Richardson.
Kathy is notified that she needs to review the request.
Kathy does not act within the set 3-day time period.
The escalation plugin escalates the request to Susanne Kober.
Susanne is notified that a request has been escalated to her.
Susanne does not act within the set 3-day time period.
The escalation plugin escalates the request to Doug Brost.
Doug is notified that a request has been escalated to him.
Doug logs into Bravura Security Fabric , and chooses to review the request originally assigned to Kathy.
Doug Brost, the delegate, is granted the same access rights as Kathy Richardson for the relevant request. For example, if Kathy is normally the authorizer for new account requests, the Authorize requests option appears on Doug’s self-service menu until he has acted on the escalated request. In other words Doug reviews the request as if he is Kathy. When a delegate authorizer views a list of pending requests, a drop-down list appears at the top of the page so that they can choose who they want to act as.
If a delegate authorizer was already assigned to a delegated request, they must act on their own behalf and for a primary authorizer (the authorizer who initially did not act on time). For example, based on the figure above:
Marc LeBlanc submits a request that requires authorization from Kathy Richardson and Susanne Kober.
Kathy and Susanne are notified that they need to review the request.
Susanne logs into Bravura Security Fabric and approves the request.
Kathy does not act within the set 3-day time period.
The escalation plugin escalates the request to Susanne.
Susanne is notified that a request has been escalated to her.
Susanne logs into Bravura Security Fabric , and chooses to review the request originally assigned to Kathy.
Susanne can modify, or even deny the request (for a business reason, for example) on Kathy’s behalf, even though Susanne has already approved the request on her own behalf.
If a primary requests a delegation, and the potential delegate does not respond in time, the delegation request is escalated to the primary’s superior. In effect, the primary’s manager becomes the delegate.
When a delegation is in place, and a delegate authorizer does not respond to a request on time, the workflow request is escalated to both the primary’s manager and the delegate’s manager.
Requirements
See Writing plugins for general requirements.
Execution points
The escalation plugin is run by the Workflow Manager Service service when:
A new authorizer, implementer, reviewer, or escalate is added to the request
The authorizer, implementer, reviewer, or escalate fails to act on the request for ESCALATION TIMEOUT seconds
The requester forces an escalation after EARLY ESCALATE TIME seconds have elapsed, by logging in to Bravura Security Fabric and clicking Escalate now on his request.
The FIRST CHANCE ESCALATION PLUGIN runs and determines that immediate escalation is required.
The time has lapsed for a previous plugin retryInXSeconds value.
The dynamic escalation time, set in the output of the plugin, is reached for the request.
Input
The input is structured as follows:
"" "" = {
"checkWillHaveEscalates" = "<true|false>"
# true, if the escalate is just added to the request
# false, if the timeout or early escalation occurs
"escalatetimes" = "<N>"
# The number of times the plugin has run for the request
"escalatingEarly" = "<true|false>"
# true, if the request is escalated early
# false, otherwise
"sessionid" = "<Session ID>"
# the session ID which spawned this request
"escalate" "<Username>" = {
"allowDelegatesToAuthorize" = "<true|false>"
"timetorerun" = "20"
}
# escalation rules defined by a user class attached to this plugin.
# this group may appear several times
"firstEscalatedTime" = "<time since Jan 1, 1970 in seconds>"
# time the request was first escalated.
"lastEscalatedTime" = "<time since Jan 1, 1970 in seconds>"
# time the request was escalated last.
"oldEscalate" "user" = { ... } # The current escalate to evaluate
# See User data.
"path" "" = {
"<primary's Profile ID>" "" = {
"subsidiary" = "<person to whom request was delegated/escalated>"
"action" = "<how this person got the power>"
# Optional; is either delegation or escalation
}
# and then that subsidiary escalated/delegated to...
"<subsidiary's Profile ID>" "" = {
"subsidiary" = "<person to whom request was delegated/escalated>"
"action" = "<how this person got the power>"
# Optional; is either delegation or escalation
}
} # the path of escalation/delegation
"primary" "user" = { ... } # authorizer or implementer that requires action
# See User data.
"request" "" = { ... }
# See Request data.
}primaryis the authorizer who was initially in charge of doing something about the request. This will not change for each subsequent escalation.oldEscalateis the authorizer that did not act and caused this plugin to run. This can be the primary if the primary had no delegates and did not act. This will change at each subsequent escalation.subsidiaryis a general term for someone’s delegate (from either a requested delegation or automated escalation).
Output
Output to attach new escalates:
"" "" = {
"errmsg" = "<message>"
"retval" = "<number>" # 0 means success, otherwise failure
"timetorerun" = "60" #set the initial timeout value
"escalate" "<escalate Profile ID>" = {
"primary" = "<primary>" # the primary authorizer of the request
"oldEscalate" = "<oldEscalate>" #the previous user escalated from
"escalateType" = "user"
"allowDelegatesToAuthorize" = "true|false|default"
"timetorerun" = "60" #dynamic timeout value
} # Optional; 0 or more escalates
} Valid values for allowDelegatesToAuthorize include default which uses the value of the ESCALATION IS DELEGABLE system variable.
Output to set early escalation:
"" "" = {
"errmsg" = "<message>"
"retval" = "<number>" # 0 means success, otherwise failure
"canEscalateEarly" = "<true|false>"
} Output to deny the request and end escalation:
"" "" = {
"errmsg" = "<message>"
"retval" = "<number>" # 0 means success, otherwise failure
"canEscalateEarly" = "<true|false>"
}Output to postpone escalation and reevaluate it after a set interval:
"" "" = {
"errmsg" = "<message>"
"retval" = "<number>" # 0 means success, otherwise failure
"retryInXSeconds" = "<seconds from now to escalate>"
} Escalating requests immediately when authorizers are assigned
You can use a first chance escalation plugin to determine whether a request should be escalated at the time an authorizer is first assigned to a request. If, for example, the authorizer is away, Bravura Security Fabric can then run the escalation plugin to determine to whom the request should be escalated. The most common way of determining that an authorizer is away is to check the out-of-office status of the mail account of the authorizer.
Bravura Security Fabric can also utilize user classes with this plugin point, so that if an authorizer is included in a defined user class, the request is automatically escalated.
The executable plugin-fce-exchange is a shipped first-chance escalation plugin.
Write a custom first-chance escalation plugin
Requirements
See Writing plugins for general requirements.
Execution points
The escalation plugin is run by the Workflow Manager Service when authorizers are assigned to a request.
Input
The plugin receives standard input for Request data and User data.
Output
If the output includes:
"" "" = {
"errmsg" = ""
"retval" = "0"
"authorizer" = "<authorizerID>" = {
"doFirstChanceEscalation" = "true"
} # for each authorizer
} then escalation occurs immediately. If doFirstChanceEscalation is empty or set to false, escalation occurs after the escalation timeout expires.
Configuring escalation options
To configure Bravura Security Fabric to use escalation:
If you are using a custom plugin instead of
escorgchart.pssensure that your plugin program or script is located in the plugin directory.Click Workflow > Options > Escalation.
Define one or both methods for selecting delegates:
Click Use user classes and follow the procedure outlined in Using user classes with plugin points
Type the name of the escalation plugin program, built-in plugin, or script in the ESCALATION PLUGIN field.
Type values in the following fields to control how requests can be escalated:
ESCALATION IS DELEGABLE
allows subsidiary authorizers to delegate an escalated request to another user.
ESCALATION TIMEOUT
is the time in seconds that an authorizer has to act before a request is escalated.
EARLY ESCALATE TIME
determines how soon requesters and recipients can choose to escalate the request early, by clicking an Escalate now button in the Requests app, before the ESCALATION TIMEOUT ends.
If required, define whether requests should be escalated as soon as certain authorizers are assigned, using one or both of the following methods:
Click Use user classes and follow the procedure outlined in Using user classes with plugin points .
Type the name of the escalation plugin program, built-in plugin, or script in the FIRST CHANCE ESCALATION PLUGIN field.
For the FIRST CHANCE ESCALATION PLUGIN, the plugin takes precedence over user classes if both are defined.
Click Update.
Any action assigned to a disabled user profile in Workflow Manager Service would be automatically escalated at assignment time