Approvals
The Approvals module stores and queues DNS 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 related actions, while we gather feedback and use cases to inform possible future updates. 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 items by users.
With Approvals, administrators can set group permission rules requiring that certain types of DNS 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 sucessfully 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, Record, or Server
- Delete: Deleting a Group, Zone, 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 / BackgroundPush: DNS Server Pushes - manual or scheduled
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 item) with the Action Type. DNS Families include DNS Servers, DNS Groups, DNS Zones, and DNS Records. 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 and Groups.
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 1B | Group 1C |
---|---|---|
Approval Group Settings:
|
Approval Group Settings:
|
Approval Group Settings:
|
Expand the following link to view example images of setting the assignments for all three groups:
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 |
---|---|---|
Approval Group Settings:
|
Approval Group Settings:
|
Approval Group Settings:
|
Approval Workflows
Initial Setup
The high level process to use when first setting up approvals is as follows:
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:
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.
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:
- Edit existing User Groups to add or remove users, in order to combine users who will need similar action types approved.
- 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!)
- Create new User Groups specifically for use with Approvals (recommended)
- 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 and Groups.
Step 3 - Assign Approval Action Settings to Groups
Assign Action and Policy Settings to User Groups from the Approvals Tab Permission Groups sub-tab:
Step 4 - Enable Notifications (Optional)
If using Approvals notifications, enable notifications for the appropriate Permissions Group(s).
From the Approvals Tab, navigate to the Permission Groups sub-tab Groups page tab:
Step 5 - Add Scheduler Task: "Approvals - Process Subscription"
If using Approvals notifications, set up a Scheduler task for "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.
Step 6 - Add Scheduler Task: "Approvals - Delete events older than 1 month"
Set up a Scheduler Task for "Approvals - Delete events older than 1 month", to occasionally clear out old and obsolete Approval request events.
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):
- Submitter makes an action (either by action type or DNS Family) that requires approval
- Submitter is notified that their action is pending approval
The requested change is sent to the Approvals Tab Pending Approvals list, and also to the DNS Resources Awaiting Approval module (the submitter may see their own submitted action under "Resources awaiting approval", but only Approvers can take approve/reject actions)
The Approver reviews the change in either their Approvals Tab Pending Approvals list, or the DNSResources Awaiting Approval module, and chooses to Approve or Reject the change:
Additional Information
See the following areas for more information on Approvals and using Approvals with DNS: