Access Flows

The sym:approval template has several steps, each of which has a default implementation. You can override these implementations by implementing Workflow Handlers.


Sym's Access Flows allow users to request temporary and auto-expiring access to sensitive resources. The requests are routed through fully-customizable escalation pathways via Sym's Python SDK, with the majority of the request-approve cycle taking place in Sym's Slack app.


Steps of an Access Flow

All Sym Approval Flows follow the same series of steps, any of which can be altered or overridden via Hooks and Reducers in the Python SDK.


Sym Access Flows have five steps:

  • Prompt: a user sees all available Sym Access Targets
  • Request: a user selects a Target and their request is routed for Approval
  • Approve/Deny: the Request is resolved, either by human action or an SDK rule
  • Escalate: If approved, the user's access is escalated in the Target system
  • Deescalate: After a Duration, the user's access is deescalated

Flows can be triggered via Slack or API; all human steps take place in Slack; and the escalate/deescalate cycle is handled via Sym platform integrations.

As requests move through the Sym system, all events are logged for audit purposes. These audits are made available via the Reporting Framework, which can then be connected downstream to any number of customer-owned destinations.


Sym Flows can be kicked off via API, too

Sym's Events API can be used instead of Slack to move through the Prompt + Request stages of a Sym Flow.

Step details


The prompt event fires when a user indicates their desire to request access to a resource (e.g. by using the /sym request Slack command). It reads the set of Targets from the Strategy specified in your Terraform.


The request event fires when a user has selected a Target to request access to, completing the necessary fields.

It reads the set of approvers to present the request to from the get_approvers reducer.

It also reads the expiration time for this request from the get_timeout reducer, and schedules an expire event accordingly.


The approve event fires when a user's request to access a given Target has been approved.


The deny event fires when a user has been denied access to a given Target.


The escalate event fires when a user has successfully been granted access to a Target, via a Strategy.


The deescalate event fires when a user's access to a Target has expired or has successfully been revoked.

Example Terraform

Like Approval-Only Flows, Access Flows hinge on a sym_flow resource that defines the fields a Sym user will see in Slack. In addition, Access Flows will contain:

  • Asym_strategy resource that defines the type of access/escalation
  • One or more sym_target resources that specify how the Strategy should be used
# The main Flow resource for an Okta escalation
resource "sym_flow" "this" {
  name  = "okta"
  label = "Okta Group Request"

  # The implementation file contains Python code 
  implementation = "${path.module}/"
  environment_id =

  params {
    # By specifying a strategy, the Approval Flow becomes an Access Flow.
    # And can manage access to the targets specified by the strategy.
    strategy_id =

    # Each prompt_field defines a custom form field for the Slack modal that
    # requesters fill out to make their requests.
    prompt_field {
      name     = "reason"
      label    = "Why do you need access?"
      type     = "string"
      required = true
    prompt_field {
      name           = "duration"
      type           = "duration"
      allowed_values = ["30m", "1h"]
      required       = true
# A target Okta group that your Sym Strategy can manage access to
resource "sym_target" "okta_admin_access" {
  type  = "okta_group"
  name  = "main-admin-access"
  label = "Admin Access"

  settings = {
    # `type=okta_group` sym_targets have a required setting `group_id`,
    # which must be the Group ID the requester will be escalated to when this target is selected.
    group_id = "00g12345xxx"

# The Strategy your Flow uses to escalate to Okta Groups
resource "sym_strategy" "okta" {
  type           = "okta"
  name           = "main-okta-strategy"
  integration_id =

  # This must be a list of `okta_group` sym_target that users can request to be escalated to
  targets = []