Hi! I’m Max, Head of Product here @ Sym. I usually write the changelogs and sometimes contribute to our Twitter. Occasionally, I write blog posts.
Sym is an approvals platform that helps you code your way out of messy access management. We ship a Terraform provider, a Python SDK, a Slack app, and a host of integrations to tools like AWS IAM, Okta, PagerDuty, and GitHub.
With Sym, you can write simple workflows that make sure the right people are approving access to the right privileged resources, at the right time, with the right context. In most cases, we can grant + revoke privileged access directly; in all cases, we produce a centralized audit record of the approval.
Ok, good talk. But why are we here today? Earlier this year, one of our customers asked us, “What would it take for us to have our customers approve requests for our engineers to access their data directly in Slack?” This is the story of why we are so excited to build that feature, and how we went about it.
But first, let’s talk about trust.
Safety and risk go hand in hand. Hardly a hot take. They tend to have a directly inverse relationship that shifts when organizations change, especially with respect to headcount, complexity of team composition, and tools. Growth: it’s tricky!
Trust is the nebulous area that sits in between safety and risk, where people have relationships with each other. Trust is built in teams, companies, and customer relationships through the shared rules, processes, headaches, successes, incidents, and chaos that govern so many interactions.
Trust appears in simple transactions, like the one we’re sharing now: somewhere between zero and 12,000 miles apart from each other, you’re trusting that this post isn’t a total waste of time, and I’m trusting that you’re going to make it to the next sentence.
In a growing organization, bad processes can have a corrosive effect on trust: we double- and triple-check each other against policies stashed away on PDFs in a long-forgotten wiki. We throw our needs into seemingly-bottomless, faceless ticket queues. We replace speed with interrogation. We do not trust – only verify. The stew “tastes,” for lack of a better metaphor, not great.
Conversely, a clean process or a tool that confers effortless safety to an organization can add delicious trust to the stew: we enjoy autonomy with guardrails, we can feel more secure in our decisions, and we can move faster, together.
At the organizational level, trust is squishier – less transactional, more of a complex stew. For added fun, when organizations grow, it’s usually due to success, which has a high correlation to the pursuit of Enterprise Contracts (heck yeah), and with them, complex audits and often-theatrical security questionnaires (oh no).
More on those in a second, and by the way, if you’ve trusted me enough to get this far, thank you.
It’s hard to argue with the doctrine of Zero Trust. Layer by layer, assume nothing, verify everything, and you will ideally end up with a scenario where all actors are authorized at all times to do exactly what they’re meant to do and nothing more.
Out at the edge, all of our technical systems are owned and operated by the humans they affect, and those humans, in turn, build networks of interaction, both with each other and with their technical systems. When these systems operate optimally, when our rules are encoded, operated, and enforced seamlessly, the trust between humans – and between humans and the tools – goes up.
We build trust in the lanes created by simple, effective tools. The best software removes toil, and through new efficiencies, improves relationships. As we remove trust from the interior of our systems, we should be conscious of how trust can increase elsewhere.
Going back to security questionnaires – if you’ve ever been on either side of one of those questionnaires, you’ve experienced low trust at the edge. The customer insists (fairly!) on knowing who can touch their data; the vendor responds (fairly!) that it’s a small number of privileged admins, and only in certain scenarios. Which scenarios? Which admins? How is it recorded? How do you get our permission?
This ceremonial negotiation speaks to the core premise of Sym: put your rules in code, cull risky default access, and build trust through shared context. If we can extend those benefits to our customers’ customers, wouldn’t that be something? Imagine replying to a questionnaire with, “Any time we need access to your production data, we will ask you, and you will approve it directly,” shaking hands, and moving onto the next question.
So back to the top: one of our customers asked us, “What would it take for us to have our customers approve requests directly in Slack?”
Well, Bob, let’s unpack it!We can call a user who can approve and reject requests, but not initialize them, a “guest” – so we’re going to need a guest role in our backend and CLI.We can assume guests will belong to email domains other than the primary domain belonging to the Sym customer – so we’ll need to support rules for secondary domains.Of course, not all Sym workflows will want guest interactions. We’ll need to do some minor spelunking into what Slack supports here, and what kinds of payloads we see when a guest takes an action – we can probably assume workspace “Guests” and folks invited via Slack Connect will present different puzzles.Yep, totally different. We need to solve for both.We’re gonna need some documentation for all of the above.
With all of those building blocks identified and accounted for, we were able to tie it all together into a deceptively simple-sounding feature: Sym now supports guest approvals via Slack Connect.
Going back to this idea of trust – how do we know when we’re effectively increasing human-to-human trust in a given system? There are soft signals: an OAuth grant tells me exactly what you can do on my behalf; a SOC 2 report tells you what systems I’ve put in place to guard my software processes, and by extension, your data. I might even assure you that your production data will never be accessed without your explicit permission via email. All of these measures create the promise of trust.
But a little dialog that pings you, with a little button that you hit in a way that is shared, visible, and auditable? That delivers on the promise of trust by providing a real, hands-on way for a customer to participate in an approval.
For growing organizations in secure domains that live or die on this ability to create trust – like Sym, and like so many of Sym’s customers – this is the highest prize. With this one little Approve button, we can help you build the kind of trust that underpins incredible customer relationships.
Now that we’ve built the infrastructure to support customer approvals, the next places we can turn are more complex approvals – say, both a customer and your manager – and channels outside of Slack like email, Zendesk, etc.
Slack Connect was an obvious starting place for us: Slack is where our UI currently lives, and Sym has a strong cultural fit with other high-touch organizations that are trying to learn rapidly from their own customers. But it’s just the beginning of what we hope will be a long journey of helping our customers build trust with their customers, and their customers, and so on.
Fractal trust – now there’s an idea…
