Skip to main content
The following examples illustrate the different use cases for our Request Review scripts, and how you might implement it in your environment.

Auto-approve based on duration

Route based on resource type

Validate custom fields

Check prerequisite access

Grant a required group on approval

Add the user to a group that the requested access depends on, such as the SSO group an app needs, and then approve. This example uses the groups module and is available as the Grant a required group on approval template in the OpalScript editor. Use this script as the only reviewer in the final approval stage, after your human reviewers. It always approves. If the user can’t be added to the group, for example because they’re already a member, it still approves and includes the error in its comment. Replace the group ID with your own.

Separation of duties: remove a conflicting group

Before approving, remove the user from a group that must not be combined with the access they’re requesting. This example uses the groups module and is available as the Separation of duties: remove conflicting group template in the OpalScript editor. One groups.remove_user call removes all of the user’s direct memberships in the group, and does nothing if the user isn’t a member. If the removal fails, or if the user’s only access comes from a nested group, an on-call schedule, or break-glass access, the script doesn’t approve. It adds a comment and the request continues to its human reviewers. Replace the group ID with your own conflicting group.

Complex multi-condition logic

Block cross-region access

Deny a request when a Europe-based requester asks for a US-based resource. Location comes from tags that Opal already keeps in sync, so the script needs no external call and no secret. The script fails closed to human review: when the requester’s country or a resource’s region can’t be determined, it takes no decision and the request continues to its normal reviewers. A deny applies to the whole request, so one US-based resource in a multi-resource request denies all of it. Point the two tag keys at your own tagging scheme. Tag values are compared uppercased, so list whatever spellings your tags use in uppercase (for example both DE and GERMANY).

Deny based on device posture with FleetDM

Deny an access request when the requester’s device is failing any FleetDM policy, and approve otherwise. It shows the full pattern for the http and secrets utility modules: secret composition for auth, a fail-closed helper, and terminal actions.deny / actions.approve. Prerequisites (OpalScript → Advanced, on the Secrets and Allowed hosts tabs):
  1. Egress allowlist: add your Fleet host, for example fleet.example.com with scheme https. It must be a public host. The SSRF-safe client blocks private and loopback addresses even when allowlisted.
  2. Secret: add FLEET_API_TOKEN holding the raw token (no Bearer prefix). The script prepends Bearer with secret composition, so the combined value stays opaque.
Fleet’s host search matches hostname, serial, uuid, or ipv4, not email. The email-to-host link lives in Fleet’s device mapping, so this matches the requester’s email against each host’s mapping, making one call per host until it finds a match. The per-execution budget is 50 HTTP calls, so this suits small fleets and demos. For larger fleets, page through /hosts (page / per_page), narrow by team or status, or maintain an email-to-host index outside the script. Otherwise, a requester whose host is not on the first page is denied as unmapped.
Last modified on November 3, 2026