Examples

Auto-approve based on author team membership

To auto-approve changes made by members of a specific team, check author.teams. Use a policy variable to make the team name configurable without editing the expression:

type == "UPDATE_ENTITY" && {{ policyVariable.approvedTeam }} in author.teams
  ? approve("Change authored by a member of the approved team.")
  : no_op()

Define approvedTeam as a STRING variable with the team name as its value. This lets you update the approved team through policy configuration rather than by editing the expression itself.

To auto-approve based on the author already holding a role on the resource rather than team membership, use authorRoles from referencedResources:

type == "UPDATE_ENTITY" && "entity:operator" in referencedResources.installation.authorRoles
  ? approve("Author is an entity operator for this installation.")
  : no_op()

Require a specific team for a specific Entity type

To write a policy that only applies to a particular Entity type, guard on type first, then on request.apolloEntityType:

type == "UPDATE_ENTITY" && request.apolloEntityType == "network-security"
  ? require_team("platform-security", "Security team must approve network configuration changes.")
  : no_op()

This policy produces a reviewer requirement only for network-security Entities. For all other change types and Entity types, it returns no_op() and Apollo moves on to the next policy.

Combine requirements across policies

Because all enabled policies are evaluated and their results combined with AND semantics, adding a new policy adds a requirement that must be satisfied alongside any requirements from existing policies.

For example, if a default policy already requires an Entity operator to approve UPDATE_ENTITY changes, enabling this additional policy means every UPDATE_ENTITY change must also be approved by the security team:

type == "UPDATE_ENTITY"
  ? require_team("platform-security", "Security team must approve all entity config updates.")
  : no_op()

Both requirements must be satisfied before the change can be applied. Individual policies do not require context on other policies.

Auto-approve installing a specific Module

Module installations generate individual Entity change requests for each Entity in the Module. All enabled policies evaluate each of these changes, so adding a new standalone policy that returns approve() for a trusted Module is not sufficient. The existing Entity policies would still run and produce their own requirements.

To auto-approve installations of a specific Module, add the Module check to the beginning of each existing Entity policy that would otherwise require approval. Add this check before other branches so it will immediately approve() before the default requirement is reached:

type == "UPDATE_ENTITY" && request.apolloEntityType == "service" ? (
  is_trusted_module_request(author, metadata, editors)
    && "module" in referencedResources
    && referencedResources.module.name == "my-trusted-module"
    ? approve("Trusted installation of my-trusted-module.")
    : require_operation(referencedResources.installation.rid, "entity:approve-config-update", "Entity operators must approve entity config updates.")
) : no_op()

The guard "module" in referencedResources is required because the module key is only present when the change request involves a single Module installation. Apply the same addition to each default policy that covers Entity types included in the Module, typically the Entity config update, Entity settings update, and Entity delete policies.

Gate on a Module release version

For Entity changes that are part of a Module installation, referencedResources includes both module and moduleRelease keys. Use referencedResources.module.name to identify the Module by its Product ID and referencedResources.moduleRelease.name to check the release version:

type == "UPDATE_ENTITY" && "module" in referencedResources
  && referencedResources.module.name == "my-module"
  && referencedResources.moduleRelease.name == "1.0.0"
  ? approve("Approved installation of my-module version 1.0.0.")
  : no_op()

This policy auto-approves installations of a specific version of a specific Module. For all other changes, it returns no_op() and other policies continue to evaluate normally.

Auto-approve egress to a trusted host

Use request.data.all(...) to check that every policy in a CREATE_EGRESS_POLICIES request targets a specific host and port before auto-approving:

type == "CREATE_EGRESS_POLICIES" && request.data.all(policy,
    policy.address.type == "dns"
      && policy.address.dns == "example.com"
      && policy.port.port == 443)
  ? approve("All policies target example.com on port 443.")
  : no_op()

The all(...) macro ensures the approval only fires when every policy in the request matches. If any policy targets a different host or port, the expression falls through to no_op() and other policies continue to evaluate normally.