Controlling Who Can See What Flows

Sym makes it easy to control which users are allowed to see which Flows.


Slack-only feature

For now, the FlowsFilter will only be invoked when the request comes from Slack.

Therefore, we highly recommend not using it as a security feature, but more as a convenience for display purposes. All flows will still be visible in the web app.


When you make a Sym request in Slack by running /sym, you will see a list of Flows that you can choose.

You can change this list of options depending on the requesting user. More specifically, you can implement a FlowsFilter that will scope down the list of displayed Flows based on custom logic.



First, ensure that your Sym Terraform Provider version is >= 3.5.0, if not please upgrade your version with terraform init -upgrade.

The FlowsFilter object

In your Terraform configuration, you can specify a sym_flows_filter resource that will point to a Python implementation file containing custom logic to determine which Flows should be displayed to whom.

Note that this implementation file should be different from the implementation file passed into sym_flow resources. The sym_flows_filter implementation will be invoked outside of the context of a specific Flow and concerns the Flow Selection logic.

Furthermore, your organization may only have one sym_flows_filter resource, because it will be invoked for all users on Flow Selection.

If you would like to use integrations in the sym_flows_filter implementation, you will also need to pass them in via the integrations attribute in the Terraform resource.

You can also pass in a string-to-string map of variables via the vars attribute.


Define once, pass many times

Even if you've already passed integrations (like PagerDuty) into your Flow's main implementation file (usually, you'll need to pass them in here, too.

In this example, we will use PagerDuty to determine whether or not to display admin-related Flows to the requester. Note that both vars and integrations may remain empty if your Flow filtering logic does not need to rely on them.

resource "sym_flows_filter" "this" {
  implementation = file("${path.module}/")

  vars = {
    incident_threshold = 1

  integrations = {
      # See the PagerDuty integration page for information on how to 
      # define a PagerDuty sym_integration
      pagerduty_id =

The flows_impl file

In the, define a get_flows reducer. This logic will be used to determine which options should be displayed during Flow Selection. get_flows will be invoked each time a user runs /sym from Slack.

The get_flows reducer

This reducer is defined as follows:

def get_flows(user: User, flows: List[Flow], flows_filter_vars: Dict[str, str]) -> List[Flows]:
    """Returns a list of Flows visible to the given User.

        user: The User that invoked /sym.
        flows: The complete list of Flows in the Organization.
        flows_filter_vars: A dict containing the variables specified in the 
                           `sym_flows_filter.vars` attribute in Terraform.

        A List of Flows that the current User may see.

The return type should be a list of Flow objects. For example,

from sym.sdk.annotations import reducer
from sym.sdk.integrations import pagerduty

def get_flows(user, flows, flows_filter_vars):
    incident_threshold = int(flows_filter_vars["incident_threshold"])
    if (pagerduty.is_on_call(user) and len(pagerduty.get_incidents()) > incident_threshold):
        # Show all flows, including admin flows, if the user is on-call 
        # and there is more than one incident.
        return flows
        # The user is not on call or there are not enough incidents. 
        # Hide admin flows from being requested.
        return [flow for flow in flows if "admin" not in]

If there is more than one active PagerDuty incident and the user is on-call, they will be able to see all Flows in the organization, including the ones marked as admin Flows.

Otherwise, they will see a subset of Flows that do not include admin in their names as defined in Terraform.