Approvals

The Approvals module stores and queues DNS and DHCP actions made by selected User Groups, and sends those actions to a Pending Changes list for administrative review.  Later, an administrator (or combination of administrators) can approve or reject these stored actions.

The admin Approvals Tab contains two sub-tabs: Pending Approvals and Permission Groups, which are the primary areas to manage Approvals items.

Currently, Approvals is available only for DNS and DHCP related actions. If you are interested in providing feedback, a use case, or requests for future additions to the Approvals system, please contact feedback@6connect.com.



Approvals Tab - Overview

The ProVision Approvals system gives administrators an additional layer of flexibility and oversight to manage which changes are allowed to DNS or DHCP items by users.

With Approvals, administrators can set group permission rules requiring that certain types of DNS / DHCP changes made by a user are either 1) automatically denied or 2) approved by an administrator. In the latter case, one or more admin group(s) must be assigned to approve those action types.

Viewing requested changes and managing the group permission rules are both managed from the admin Approvals tab, under the Pending Approvals and Permission Groups sub tabs.

Approvals Fundamentals (Before you Begin)

The approvals system revolves around three primary concepts: Policies, Family-Action Types, and User Groups. An understanding of all three is necessary before setting up Approvals, and additional steps may need to be taken to ensure proper use of Approvals - such as creating additional User Groups.

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:

  • Deny: The type of change is immediately denied when a member of the User Group attempts to perform that action. 
  • Action to be Approved: The type of change made by any user in the associated User Group will require an administrative user to approve the change (The approver must be included under a "Must Approve" group for the same action).
  • Must Approve: 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 "Must Approve" 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.

Ensure that for any group/action set with an "Action to be Approved" policy, another group is set with "Must Approve" for the same family-action type. Failure to provide groups for both submitter and approver may result in changes not being processed, due to not having a user assigned to approve the request.

Family-Action Types

In Approvals, the "Action" listed in the Pending Approval information or when setting Approval Permission Groups will be one of the following change types:

  • 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.

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 a 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 attempt it. 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.

Further fine-tuning of the action types for permissions is done by selecting the combination of "Family" (type of DNS / DHCP item) with the Action Type:

  • DNS Families include DNS Servers, DNS Groups, DNS Zones, and DNS Records.
  • DHCP Families include DHCP Servers, DHCP Groups, DHCP Pools, and DHCP Reservations

Each type of action can be performed on each family, so when setting up Approval Permission Groups you may choose to set the policy for the entire Family (ex: "All DNS Group actions"), Action (ex: "Add actions for all DNS Families"), or just a specific combination (ex: "Only DNS group Delete").

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. 

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

  • That administrators who will be approving change requests are included in a Global Admin (TLR level + Admin) group, in order to access the "Approvals" tab and perform Approve/Reject responses. 
  • That users included under the same User Groups are similar in terms of what types of tasks they perform and what level of Approval oversight is needed. 
    • Example: If "Group A" consists of seven users - four who will need all Add and Delete actions approved, two who do not, and their manager (who will approve their actions)- you may need to move those users under three groups: 1) A group for those requiring action approvals, 3) a group for the users not requiring approvals, and 3) the manager associated with a Global Admin group in order to access Approvals.
  • That any user that will be performing DNS Actions with Approvals are in a User Group with appropriate 'resource' CRUD permissions to perform the actions subject to approval.
    • Example: If a user needs zone creations approved, ensure that they have (at the very least) "Create" and "Read" resource permissions so that they can view DNS information and create a zone!
  • Consider limiting groups associated with Approvals to only those users relevant to the Approvals system, especially if using Approval Notifications. Approval Change Notifications are emailed to all users of the associated User Group - not just the submitter / approver. Be conscientious of colleagues' email boxes and consider which users may not appreciate being included with notifications.

Sample Group Scenarios

Below are a couple of sample scenarios to illustrate common Approval situations, with example notes on Approval Settings.

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. 

Group 1A (Admin)Group 1BGroup 1C
  • Global Admins (Full TLR User Group Perms + Admin)
  • All Admins in this group can approve any change requests
  • It doesn't matter which Admin user approves a request

Approval Group Settings:

  • Set to policy "Must Approve" for all DNS Family / Action types
  • Tip: Click the quick select checkbox next to each DNS Family name to select all actions under that family
  • Users with minimal oversight
  • Can work fully in all DNS family areas
  • Only needs admin approval for DNS Pushes

Approval Group Settings:

  • Set to policy "Action to be Approved" for "Push" actions only, under each DNS Family in Group Assignment
  • Users with high oversight
  • Not allowed to Add or Delete any DNS item
  • Needs admin approval for all DNS Push and Updates

Approval Group Settings:

  • Set to policy "Deny" for "Add" and "Delete" actions under each DNS Family; save
  • Open again, set the policy to "Action to be Approved", and select "Update" and "Push" actions under each DNS family; save.

Expand the following link to view example images of setting the assignments for all three groups:

These examples use the "Assign" button for the Group under the Approvals Permission Groups sub-tab, Groups page.

Scenario 1

Group A:

Group B:

Group C, Deny Policy:

Group C, Action to be Approved Policy:

These settings may also be set by Action Type instead of Group, from the Approvals Permission Groups sub-tab, Actions page.

Scenario 2: Multiple Approver Groups/Specific user, with Restricted Families

Two Admin approval groups exist: One general Approver group that can approve any action type, and a second Group containing one person, Bob, who must sign off on any action taken under DNS Groups. 

Group 2A (Admin Approvers)Group 2B (Admin Approver Bob)Group 2C
  • Global Admins (Full TLR User Group Perms + Admin)
  • All Admins in this group can approve any change requests
  • It doesn't matter which Admin user approves a request
  • DNS Group changes require multiple levels of oversight- from both this group and Bob

Approval Group Settings:

  • Set to policy "Must Approve" for all DNS Family / Action types
  • Tip: Click the quick select checkbox next to each DNS Family name to select all actions under that family
  • Global Admins (Full TLR User Group Perms + Admin)
  • Only contains one user - Bob, who specifically must approve of any change to DNS Groups

Approval Group Settings:

  • Set to policy "Action to be Approved" for "Push" and actions only, under each DNS Family in Group Assignment
  • Full Access throughout DNS
  • Not allowed to work with DNS Servers, even if they might have admin level access otherwise
  • Changes to DNS Groups and DNS Records require approval

Approval Group Settings:

  • Set to policy "Deny" before quick-selecting the DNS Servers Family; save
  • Open again, set the policy to "Action to be Approved", then quick-select the "DNS Groups" and "DNS Records" families; save.

Approval Workflows

Initial Setup

The high level process to use when first setting up approvals is as follows:

  1. Review User Groups and Approval Process Needs

    Step 1 - Review Existing User Groups and Process Needs

    When setting up Approvals for the first time, review the information in the previous section under "Approvals Fundamentals" to ensure a basic understanding of how Policies, Actions, and User Groups relate together in Approvals. 

    Then, take a few minutes to think about the following questions to get a better sense of how to use Approvals with your specific organization:


    Who are the users that perform DNS / DHCP tasks, and at what level? 

    Affects which users should be included in what User Groups  

    What ProVision User Group(s) are they in? 

    Approvals settings are applied to the User Group, not individuals - ensure users with similar oversight needs are grouped together

    What actions made by a certain user group should be automatically denied, if any? 

    Assign the "Deny" policy to that Action/User Group combination

    What actions made by a certain user group should require oversight (admin approval / rejection)? 

    Assign "Action to be approved" to that Action/User Group combination

    Who is the admin / User Group that will make the final approval on a change? 

    Ensure the approver(s) is in a User Group with the "Must Approve" policy assigned for the actions requiring approval

    Should any changes require multiple admins / User Groups to approve it in order to execute? 

    A single user from every group assigned with "Must Approve" for the action must approve the action for it to succeed 

    If two admins are required to both  separately agree on a change, they should be under two separate User Groups assigned "Must Approve"

    What User Groups would need to receive email Approval Status notifications, and on what type of actions? 

    Affects whether to enable notifications and set up the scheduler task to send the notifications, and to what User Groups. When enabled, all users of the relevant group(s) will receive the email(s)

    Once your User Groups are optimized for use with Approvals, you may want to write down a quick note on which Action Types and policies are planned for each group. 

  2. Edit User Groups / Create Approvals-Specific User Groups, if needed

    Step 2 - Add or Edit ProVision User Groups

    From here, depending on the answers to the questions in step 1, you may need to do one or more of the following from the Users tab:

    1. Edit existing User Groups to add or remove users, in order to combine users who will need similar action types approved.
    2. Verify the User Groups have appropriate CRUD permissions set to perform the action(s) to be approved (e.g, you may have previously removed "Create" permissions for a group, but if the intent is now for those users to have "Add" actions approved by an Admin, the submitter will need User Group resource "Create" permissions back!)
    3. Create new User Groups specifically for use with Approvals (recommended)
    4. Associate users with different, or additional User Groups (remember - users can be associated with multiple groups!)

    For more information on adding and editing ProVision User Groups, see Users & Permissions, Global Permissions, and Working With Users. 

  3. Assign Action and Policy Settings to User Groups

    Step 3 - Assign Approval Action Settings to Groups

    From the Approvals Tab, navigate to the Permission Groups sub-tab.

    Then, under the Groups page tab, find the ProVision User Group you want to assign a policy to and click "Assign".

    Clicking the "Assign" button for a group brings up a checklist to select what policy to apply to the group for what Family and Actions (i.e. DNS Zone 'Add' or DNS Group 'Update'). Select either "Deny", "Action to be Approved", or "Must Approve Action" under Policy. Once you've selected a policy, you can "quick-select" all actions for a DNS Family (Severs, Groups, Zones, Records) by clicking the checkbox next to the family name, or only select individual action types for each Family.

    When done, Click "Assign", and repeat as needed for other Policy types or User Groups.

  4. If using Approvals notifications, enable notifications for the appropriate Permissions Group(s)

    Step 4 - Enable Notifications (Optional)

    From the Approvals Tab, navigate to the Permission Groups sub-tab Groups page tab.

    Click on the group name for which you want to set notifications - the Group Permissions Detail page will provide additional information on the group's settings.

    For any Family/Action that you want to enable notifications, click the checkbox under "Enable Notifications". All users of that group will get email notifications when a change of the selected type(s) are made.

  5. If using Approvals notifications, set up a Scheduler task for "Approvals - Process Subscription"

    Step 5 - Add Scheduler Task: "Approvals - Process Subscription"

    The "Approvals - Process Subscription" task processes approval request events and handles the sending of notification emails to subscribed Approvals Groups - this task must be created and running on a regular interval in order for Approval Notification emails to be sent.

    In order to receive the most up to date information in the Approval Notifications, is recommended to create this task with a run time of "every 5 minutes" and no end date.

    For information on setting up Scheduler Tasks, see Scheduler Tab.

  6. Set up a Scheduler Task for "Approvals - Delete events older than 1 month", to occasionally clear out old and obsolete Approval request events

    Step 6 - Add Scheduler Task: "Approvals - Delete events older than 1 month"

    The "Approvals - Delete events older than 1 month" task deletes any Approvals history events older than 30 days.

    It is recommended to set this task to run monthly with no end date, to clear out obsolete approvals items, reduce data storage space needs, and reduce approvals page load time.

    For information on setting up Scheduler Tasks, see Scheduler Tab.

Daily Use

On a day-to-day basis after initial setup, an Approvals Workflow will be similar to the following (with "Submitter" as the user whose actions require approval, and "Approver" as the admin with the ability to approve/reject the change):

  1. Submitter makes an action (either by action type or DNS / DHCP Family) that requires approval
  2. Submitter is notified that their action is pending approval

  3. The requested change is sent to the Approvals Tab Pending Approvals list, and also to the Resources Awaiting Approval module for the relevant area (the submitter may see their own submitted action under "Resources awaiting approval", but only Approvers can take approve/reject actions).

    The Pending Approvals list is under the Approvals Tab. It shows Approvals events (change requests) for which the user has the ability to Approve or Deny - it does not show approval requests for all of ProVision or those for other users.

    A "Resources Awaiting Approval" module will display in selected DNS / DHCP pages to Users with Admin / Approval permissions, if a change has been submitted on that page that is pending approval by the User's Approval Group. 

  4. The Approver reviews the change in either their Approvals Tab Pending Approvals list, or the Resources Awaiting Approval module, and chooses to Approve or Reject the change. Events may be approved / rejected individually, or multiple events may be selected for bulk approval / rejection by selecting the desired checkmarks, expanding the "Actions" menu, then selecting either "Approval All" or "Reject All" for the selected events.


    1. If Approved, and no other groups need to approve it, then the change executes and is saved. A status change notification email is sent, if enabled. 
    2. If Approved, and is waiting approval from an additional User Group, the change continues to be held as Pending, until the other group responds (Both groups must "Approve" for the change to execute). A status change notification email is sent, if enabled, stating that the change is awaiting another Group.
    3. If Rejected, the change is not executed. A status change notification email is sent, if enabled. 


    Example Notification Email:


Additional Information

See the following areas for more information on Approvals and using Approvals with DNS: