Master Approvals

The master approval is the top of the approval workflow configuration.  This feature is where you combine your approver lists, your routing and exception behaviors and providing a global name for the approval which is the name that will be visible to administrators.  Master approvers must be configured and saved before approval workflows can be assigned to access requests.  This article will walk you though how to configure a master approval.

Defining escalation conditions starts with access the "Escalation Conditions" configuration as seen below:

The configuration process begins by clicking "Add", and you will be re-directed the the configuration screen:

Configuring an approval is done from the above screenshot.  Let's walk through each configuration option so you can gain an understanding of the depth of functionality this feature can provide your organization.

Approval Overrides

This feature is reserved for certain scenarios where an organization's business requirement allows for an override of the approval process, therefore skipping it.  As the feature is configured, you will understand how overrides may apply to your organization.  Below is a screenshot of a configured override:

Step 1 is define your override condition.  In this case, we will override the master approval configuration and skip to a certain level of approval if the beneficiary is the COO.  The override condition will look like this:

Once the override criteria is defined, administrators can configure the workflow to take 1 of 2 available actions.  (1) Auto Approve the request, or (2) Select a specific approval level to skip to when the override condition is met.  Below, we are configuring the approval workflow to skip to level 2.  Since the COO is the beneficiary of the request, we are skipping to the CEO approval layer of the workflow:

This configuration will skip over the first approval level and initiate level 2.  Here are the defined levels for this example:

When defining approval conditions, consider these as separate and distinct layers of the master approval process.  As you defined each approval condition, you may have specified multiple approver lists for one approval condition and only a single approver list for another.  You may have also configured the routing manners and exception behaviors differently for each defined approval condition.  So, as you construct your master approver process, you'll need to understand a few concepts.

1. Each approval level is mutually exclusive regarding the corresponding approval conditions defined.
   
   
2. You'll need to pay attention to the global "Timeout Behavior" settings just above the listing of the approval levels.  While each approval condition (approval level) allows administrators to define timeout windows, it is at the master approval level where you define the actions you want taken in the result of a timeout (for the master approval as a whole).  You'll see "Escalate", "Assign to the next level" and "Deny".  These three options should be self-explanatory.  You'll notice that "Escalate" is disabled in the above configuration.  This is because the Fischer engine is aware that no escalation condition has been defined for this particular master approval.  If an Escalation condition is defined, "Escalate" will become enabled and a selectable option for the scenario where an approval level times out.

Approval Levels

It is also important that you understand the other options / decision points you have as an administrator.  First is determine the correct order of execution for your approval levels.  The order will execute top down, so in the above scenario the "Basic Approval Condition" and it's associated approver list(s) and routing manners will initiate first and the second level "CEO Approval Required" will not initiate until the first level is completed.  You can change the order in which the approval levels execute by select the radio button next to the approval condition and clicking "Move Up" or "Move Down".

Execution Criteria

The "Execution Criteria" configuration enables administrators to control if and when a particular approval level should be initiated.  Upon clicking "Select", the following Execution Criteria configuraiton screen is displayed:

Administrators have the option to always execute this approval level anytime this master approver is invoked, or it can specify criteria that will determine when this approval level will be invoked.  If we select "Specify Condition"  the following screen will appear:

From this screen, administrators can configure a particular condition that will invoke the approval level.  Note that this is a condition to execute the approval level and NOT a condition to skip or override the level.  This level of granularity in configuration allows organizations to truly control how and when approval levels are executed.  And if done properly, you can limit the total number of approval configurations you need to create altogether.

Defining your Escalation Conditions for your Master Approval

The next step in defining your  master approval is to determine if escalation conditions are required.  Note that we discussed Fischer's approval feature is built bottom up previously, so you should already have escalate conditions defined.  If you do not, you will need to exit out of your master approval configuration and define your desired escalation conditions before you can include them in a master approval.

If you do define one or multiple escalation conditions in your master approval, the "Escalation Level" will become important in your approval condition configuration.  For each defined approval condition, you can correlate a distinct escalation path.  If no escalation path is defined, and multiple escalation conditions are configured, Fischer will treat the multiple levels of escalation the same as it would treat multiple levels of approval and execute them from top down for any escalation that may result from your master approval configuration.  

Defining Notify Conditions for your Master Approval

The last configuration item that is required before a master approval can be built is the notify conditions.  Note that this is the first item you configured and you'll want to make sure you pay attention to the context of the approval workflow to properly determine which set of notifications should be defined and leveraged by the master approval.