Approvals

Policies

When setting up Approvals Permission Groups, a policy will need to be selected to apply to the User Group / Family-Action Type combination selected. The set policy determines how the Approvals system handles an attempted change by a member of the associated User Group.

There are three available policies:

• Submit Action: The change made by any user belonging to the associated User Group will require an administrative user to approve the type of change.

  • The approver must be included under a "Approve Action" group for the same action.

• Approve Action: A user from the group must approve the action for it to be removed from the "Pending" list, and successfully execute.

  • If more than one group is assigned with the "Approve Action" policy for an action, all groups must have a user from that group approve the action for it to execute.

  • If the change has only been partially approved, its status will be "Pending, awaiting approval from others" and no action will be executed until all groups have provided a response to the action.

• Deny Action: The type of change is immediately denied when a member of the User Group attempts to perform that action.

Family-Action Types

In Approvals, the "Action" listed in the Pending Approval information (or when setting Approval Permission Groups) will be a combination of the Family (e.g. DNS module) plus an action method. The available actions differ according to what family module is selected. Example actions include:

• Add: Creating a new Group, Zone, Pool, Record, or Server

• Delete: Deleting a Group, Zone, Pool, Record, or Server

• Update: Any change to an item that isn't Add, Delete, or Push - such as a settings change, renaming, or entering a value in a field. 

• Push: DNS or DHCP Server Pushes - manual or scheduled

• Change Group: Moving a DNS Zone from one Group to another.

• Bulk Move Zones: Moving all DNS Zones in a Group to another.

• IPAM Assignments: Direct Assign, Smart Assign, or Unassign IPAM netblocks

When setting up Approval Permission Groups you may choose to set the policy for the entire Family (e.g., "All DNS Group actions"), or limit to specific Actions (e.g. Submit Action only for "DNS Group Delete").

Action Permissions vs. CRUD Group Permissions

It is important to note that Action types in Approvals is related-to-but-different than CRUD permissions as set in User groups. Although the "Add" Action type and "Create" CRUD permission seem the same, the action type "Add" only applies to one specific event occurring, rather than a holistic overarching system-level permission.

In order to perform a certain Approval Action Type, a user must already have the CRUD permissions to both view and attempt the action.

The CRUD permissions determine whether the user can even view an area or attempt an action to begin with, Approvals Policies on Action Types determine what is done with the Action after the attempted change.

User Groups

Approvals uses ProVision User Groups to determine which users must have a change approved, denied, or can approve others' actions. Therefore, User Groups must be set up with the appropriate users and basic permissions under each group before using Approvals.

For information on setting up User Groups and how the basic permissions structure works in ProVision, see Users & Permissions, Global Permissions, and Working With Users. 

Review User Groups

Before using Approvals, a review of your user and User Groups is highly recommended to ensure the following:

Scenario 1: One Approver Group, with Restricted Actions

One Admin group and two DNS worker groups with different levels (high - low) of oversight needed, with restrictions set for particular Action types. 

Scenario 1 Walkthrough

1. Ensure that each group is created with appropriate permissions from the Users tab.

   1. Group 1A should have full Admin permissions on TLR

   2. Group 1B should have, at minimum, full resource permissions to cover all DNS Actions

   3. Group 1C should have full resource permission to view and access DNS Actions for the Approvals system to require approval on DNS Update/Push actions, and to Deny actions on DNS Add or Delete items.

      1. Note: If Group 1C were not allowed to Add/Delete any resource system item (as opposed to denying only DNS Add/Delete), then the User Group would be set to disable Resource Add/Delete, instead.

2. Once User Groups & Permissions are set from the Users tab, navigate to the Admin → Approvals tab. From there, view the Permission Groups → Groups sub-tab. Click the Manage Permissions button for the desired group.

3. Click on the the applicable policy tab(s) - Submit Action, Approve Action, or Deny Action - and select which actions to apply to that group under that policy. Click Save Changes once you’ve completed selections for that group.

4. Repeat Manage Permissions for Group 1B and 1C:

4. Once all policy selections are complete, you can review a color-coded count of the applied submit (orange) / approve (green) / deny (red) policy actions on the Approvals Permission Groups list.

Scenario 2: Multiple Approver Groups/Specific user

Two Admin approval groups exist: One general Approver group (2A) that can approve any action type, and a second Group (2B) containing one person, Bob, who must sign off on any action taken under DNS Groups. The user group (2C) is to be denied actions on DNS Servers, and any DNS Group/Record actions require approval.

Under this scenario, you would set up the User Groups similar to scenario 1, except that group 2B would be a full permission admin group containing only the user Bob.

If a user in group 2C attempted a DNS Group update, their change would be sent to both admin groups, and both a Group 2A admin and Bob would have to approve the change for it to complete.