Abbey Docs
  • 👋Welcome
  • Getting Started
    • Quickstart
    • Step-by-Step Tutorials
      • AWS: Managing Access to Identity Center Groups
      • AWS: Managing Access to Identity Center Permission Sets
      • AWS: Managing Access to IAM Groups
      • Azure AD: Managing Access to Groups
      • Confluent: Managing Access to Kafka ACLs
      • Databricks: Managing Access to Managed Tables in Unity Catalog
      • Databricks: Managing Access to Groups
      • GitHub: Managing Access to Teams
      • Google Cloud: Managing Access to Groups
      • Google Workspace: Managing Access to Google Groups
      • Kafka: Managing Access to ACLs
      • Okta: Managing Access to Groups
      • Postgres: Managing Access to Roles
      • Snowflake: Managing Access to Tables
      • Tabular: Managing Access to Apache Iceberg Roles
      • Tailscale: Managing Access to ACLs
      • Vault: Managing Access to Groups and Policies
      • Integrating Abbey with Terraform Cloud
      • Using Abbey with Atlantis
      • Using Abbey with Spacelift
    • Starter Kits
  • How Abbey Works
    • How Abbey Works
    • Key Concepts
  • Build a Grant Kit
    • Get a Starter Kit
    • Connect a Repo
    • Create a Grant Kit
    • Link Identities
    • Write Access Policies
    • Deploy Your Grant Kit
    • Request Access
    • Approve or Deny Access Requests
  • Use Cases
    • Time-Based Access
      • Expire After a Duration
      • Expire At a Specific Time
    • Approval Workflows
      • Using a Single Approval Step
      • Using Multiple Approval Steps
      • Conditionally Skip Approval Steps
  • Admin
    • User Roles
    • Sign-in and MFA
      • Sign-in Methods
      • Multifactor Authentication (MFA)
      • Enabling Single Sign-On
    • Sources
      • PagerDuty
      • Directory Sync
    • End User Notifications
    • Manage API Tokens
  • Reference
    • Grant Kits
      • Workflows
      • Policies
      • Outputs
    • Referencing Users and Groups
    • Linking Application Identities into Abbey
      • Why do I need to link application identities?
      • How do I Link Application Identities?
      • Supported Application Identity Types and Schemas
      • Application Data Object
    • Access Policies
      • Types of Access Policies
      • Policy Bundles
      • Inline Policies
      • Helper Functions
      • Policy Examples
    • Terms of Service
    • FAQ
      • Troubleshooting
  • Resources
    • Abbey Labs
    • Terraform Registry
    • GitHub
    • System Status
    • Privacy Policy
    • Logo
Powered by GitBook
On this page
  • Step 1. Add Another Workflow Step
  • Step 2: Add Another, Stricter Workflow Step
  1. Use Cases
  2. Approval Workflows

Using Multiple Approval Steps

In this guide, you'll learn how you can configure a Grant Kit to have multiple review steps. Each step will contain a list of reviewers required to approve or deny an access request.

We will be using the Using a Single Approval Step as a base and modify it to this use case.

Step 1. Add Another Workflow Step

Add another step to our workflow, but this time add an additional reviewer

main.tf
resource "abbey_grant_kit" "null_grant" {
  ...

  workflow = {
    steps = [
      {
        reviewers = {
          one_of = ["alice@example.com"]
        }
-      }
+      },
+      {
+        reviewers = {
+          one_of = ["bob@example.com", "carol@example.com"]
+        }
+      }
    ]
  }

  ...
}

We now have a workflow with two steps. These steps will run serially.

First, Alice will be notified to review. If she approves, Bob and Carol will be notified to review. If Alice denies the request, then the access request overall will be denied. Bob and Carol wouldn't be notified at all in this scenario.

Second, Bob and Carol are requested to review. Either of them may approve the request because of the one_of constraint was configured. Further, if Bob approved and Carol hasn't responded, the overall step will be considered approved.

Step 2: Add Another, Stricter Workflow Step

Add another workflow step and have a stricter constraint for reviewers.

main.tf
resource "abbey_grant_kit" "null_grant" {
  ...

  workflow = {
    steps = [
      {
        reviewers = {
          one_of = ["alice@example.com"]
        }
      }
      },
      {
        reviewers = {
          one_of = ["bob@example.com", "carol@example.com"]
        }
-      }
+      },
+      {
+        reviewers = {
+          all_of = ["dan@example.com", "eve@example.com", "frank@example.com"]
+        }
+      }
    ]
  }

  ...
}

We now have a 3 step workflow. The last step requires all reviewers in the list to review.

If one of these reviewers deny the request, then the overall request will be denied. If less than all reviewers approve, then the step will wait until everyone approves.

By default, Abbey waits for 1 week for pending access requests before automatically denying them. This is to reduce access request debt and ensure you have more tidy access management.

PreviousUsing a Single Approval StepNextConditionally Skip Approval Steps

Last updated 1 year ago