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:
Review User Groups and Approval Process Needs
Edit User Groups / Create Approvals-Specific User Groups, if needed
Assign Action and Policy Settings to User Groups
If using Approvals notifications, enable notifications for the appropriate Permissions Group(s)
If using Approvals notifications, set up a Scheduler task for "Approvals - Process Subscription"
Set up a Scheduler Task for "Approvals - Delete events older than 1 month", to occasionally clear out old and obsolete Approval request events
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: