SYM changelog
SYM changelog

Customer-approved access 🤝






Ok, there's a lot going on here, but tl;dr:

Sym now works across Slack Workspaces via Slack Connect.

This means that if you have customers in connected channels, you can use Sym for an auditable record of a customer granting (or denying) requests to:

  • Access or export customer data
  • Make changes to the customer's environment
  • Execute any other workflow you can express via Sym, whether it's a simple approval, a routine access flow, a Lambda trigged via SDK, or something in between.


To support this we've added:

  • The concept of a guest role
  • An allow_guest_interaction flag for Flows
  • Robust just-in-time user creation to support guests across multiple domains.

Full release notes and links to supporting documentation below. 👇

  • 🌱 Add support for Slack Connect users
  • 🌱 Add guest and admin roles (🗒️ Docs)
  • 🌱 New e2e example for MySQL access via AWS Lambda (💻 Code)
  • 🌱 New e2e example for EC2 access via SSM/IAM (💻 Code)
  • 👍 Add role to /sym whoami slash command
  • 👍 Auth0 improvements to support new roles
  • 👍 Improved first-time login experience (🗒️ Docs)
  • 👍 Updated + improved docs for symflow init (🗒️ Docs)

Same Slack app, much better installation experience 👍




We've added a few treats to our Slack App and CLI to make Sym even easier to get up and running.

Easy install experience

image.png image.png

To start, we've smoothed out our Slack install: simply go to the new installation page and click the button. The end.

Code generation is the new copypasta

Once you've installed our app and CLI, we've created an easy init command that will generate all the code for your first Approvals Flow! It's very helpful.

Off to the races

Once you've installed the Sym App + run the starter commands, you're all set to start implementing Access Flows, adding Lambdas to your SDK code, or adapting anything else from our examples repo and beyond.

Also in this release:

  • 👍 Release symflow v 2.3.0
  • 👍 Update Getting Started 🗒️ Docs with new Slack info

Support for multiple domains 🏰




Sym's Identity Discovery will automatically handle identity lookup and matching for any user in your Slack Workspace whose email domain matches the primary domain of your Sym account. Just make a request, and we'll take it from there.

But what if you have users in your Workspace with different email domains?


This would not work. Sorry. 🙁


It works! 🎉

What changed?

Sym now has support for multiple email domains (as well as single user exceptions), all of which can be managed from the symflow CLI.


It's as easy as:

symflow domains add new-domain.tld

Full notes:

  • 🌱 Add support for multiple domains in Sym Slack App (🗒️ Docs)
  • 🌱 Add symflow support for managing domains (🗒️ Docs)
  • 👍 Switch symflow login method from email to sym_org_slug
  • 👍 Release symflow v 2.1.0

A new Slack command (and lots of other treats) 👀




It isn't an everyday thing, but sometimes you need to find information about your Slack Workspace or Sym install.

You know, little things like:

  • Your Sym org_slug
  • Your Slack workspace_id or user_id

Today, there's one route to getting your org_slug (log in through the symflow CLI), and two to getting your Slack info (dig around in a browser or use Slack's SDT utility).

None of this is as easy as it should be. Until today.

Now, you can just run /sym whoami, and we'll tell you:


That's it. That's the update.

Just kidding, there's a ton more:

  • 🌱 symflow 1.9.0 release with new users commands (🗒️ Docs)
  • 👍 Add EU + tags support to our Datadog connector
  • 👍 Improved error messaging for failed identity matches
  • 🐛 Fix typo in Datadog log example
  • 🐛 Assorted bugfixes and performance enhancements

BYO dynamic identity matching 👥




For the most part, identity handling in Sym Just Works™. Make a request, compare the requesting email to the target system, and off you go.

But what if…

  • Your IAM names omit your org's email domain
  • Your Okta identities aren't keyed off email, so you'd need to do a quick user lookup + persist a different attribute?
  • You need to invoke a Lambda to match to an ID in an internal database?

Well, in those cases (and more!), you're in luck, because Sym now exposes a dynamic identity matcher that you can write straight into your Python implementation:

Identity Flow Release.png

If present, the new get_identity reducer fires as a request is made. Anything it returns will be persisted and used as an identity key for a given User + Service going forward. That's it! 🎉

🗒️ Docs and an example are here.

More notes:

  • 🗒️ Improved docs for Workflow Handlers
  • 🗒️ Improved docs for Identity Management
  • 👍 More improvements for job queueing
  • 👍 Data storage improvements

Tailscale + Sym: a "yes code" partnership 💻🎉






Good news! If you're already using Tailscale's powerful ACLs-as-code to define network access, you can now use Sym as an approvals gate.

All you have to do is:

  • Generate a Tailscale token and share it with Sym
  • Set up your integration in Terraform as you would any other Sym resource

And just like that, you get just-in-time approval, escalation, and deescalation for any groups defined in your Tailnet, executed in seconds.


Further reading:

Docs are important (reprise) 🤓🗒️




Avid readers of this space might recall that in February, we relaunched our docs to make it easier for Sym implementers to get things up and running.

Six months later, we're at it again!

What we've done this time

We've also sprinkled some nice lil' diagrams through our docs to help newcomers get acquainted with how our platform works.


We're always looking to improve our developer experience + docs, so if you do take a look and anything seems confusing, weird, or missing, please let us know – we won't leave you hanging!

Also in this update:

  • 👍 Performance tuning for job queues
  • 👍 Better field label display in Slack blocks
  • 🐛 Assorted bug fixes, per usual

Robots acting in service of humans 🤖🍽️




"Sym for deployments" introduced the concept of implementing Sym Flows inside of tools that could benefit from bot user escalation.

Now, we're extending that concept so bot-triggered Flows can request access on behalf of human users by including either a user_email or user_id in the payload, like so:

import requests

url = ""
payload = {
  "user_email": "[email protected]",
  "context": {"key": "value"}

response =, json=payload)

The request will then go to Slack, and (as before) any additional context can be used in your Python implementation. This is helpful for workflows like:

  • Triggering Flows from inside your own admin UI
  • Inserting Sym as an approvals layer in between multiple webhook (or similar) automations

Pretty simple, pretty neat! See our 🗒️ API Reference for more detail.

Also in this release:

  • 👍 Expose persist_user_identity in the SDK to enable manual identity mapping (🗒️ SDK Docs)
  • 🌱 We rewrote like half of our 🗒️ docs
  • 🎉 No really, they're very good, you should check them out
  • 🥳 We'll probably write a fully separate release note about them
  • 🐛 Assorted bug fixes

Sym for Deployments?! 🟢





Sym helps you make great decisions that protect your most sensitive resources – and deployments are no exception.

What have we added?

Ok, we buried the lede here a little bit: Sym now has a public API. 🎉 We've also added support for non-escalating workflows, so you can:

  • Trigger a workflow
  • Wait for an approval
  • Wire whatever external API calls into your on_approve step

Like so:


We've also built a CircleCI Orb to help expedite the above workflow.

Here's some documentation

This is obviously a pretty big set of interlocking features, so we've written a couple of documents to support you on your journey:

Also in this release (are even more docs):

Flexible Slack modal headers 🗒️




A small update, but a very nice one

You can now add explainer text (with markdown support!) to your Slack modals. Add instructions, links, hopes, dreams – whatever you'd like – by adding a simple additional_header_text attribute to your Flow's params in Terraform.

Simply do this:

params = {
    name = "prod_access"
    label = "Prod SSO Access"

    template = "sym:template:approval:latest"
    implementation = "${path.module}/"

    # The extra text that we want displayed on the request modal
    additional_header_text = "For more information on Sym, please see <|click here>."

    # Prompt fields the end user will see
    prompt_fields_json = jsonencode(

And your users will get this: image.png

Full release notes: