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
  1. Use Cases
  2. Approval Workflows

Conditionally Skip 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. One of these steps will be skipped based on a condition we define in a policy.

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

Step 1. Add a Policy to Skip a Step

Let's make the second step skippable. We may want to do this for many reasons. Here are some ideas:

  1. Skip a step if someone has a privilege, for example, they're on-call.

  2. Skip a step if someone belongs to a privileged team, for example, if they're an account manager.

  3. Skip a step if someone is above a certain level in their organization.

For this example, let's skip the last step if someone is on-call, as determined by PagerDuty.

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"]
        }
+        skip_if = [
+          { bundle = "github://example-org/example-repo/policies/on-call" }
+        ]
+      }
    ]
  }

  ...
}

Note: This github repo should be the same as the repo defined in your Outputs

We added a Policy Bundle that contains rules for skipping if someone is on-call. This bundle was prebuilt using Open Policy Agent and exists within the same repo as the main.tf file.

To get a sense of the logic, take a look at the policy:

policies/on-call/pagerduty.rego
package pagerduty

skip[msg] {
  user.pagerduty.isoncall == true
  msg := "skipping review step for on-calls"
}
PreviousUsing Multiple Approval StepsNextUser Roles

Last updated 1 year ago