Salesforce access and Slack access are two different models that nobody reconciles until somebody asks. Push record detail into a broad channel and you have widened visibility past what your sharing model allows — with nothing in Salesforce recording that it happened. We design the access, retention and audit model alongside the build, not after the first review.
Trusted by 500+ organizations — including regulated teams who have to answer who could see what, and when.
What We Govern
Every one of these is the result of two systems being administered by two teams with no agreed model between them. None of them produce an error at the time.
A notification carrying amount, stage and contact detail posted into a broad channel is an access grant. It is not recorded as one, it is not reviewed as one, and the Salesforce sharing model that was supposed to constrain that data had no say in it.
Slack users are mapped to Salesforce users, and where the mapping is wrong the actions taken run in the wrong person's context. It usually shows up as notifications going astray long before anyone frames it as an access problem — but it is one.
An app was installed to solve something two years ago with whatever permissions it requested. Nobody has looked since, and the list of what it can read is longer than anyone would now approve.
External channels get created ad hoc for a customer or a vendor. There is no approval, no naming convention, no review, and no list of which outside organisations currently have a live channel into your workspace.
One retention policy applied to everything, chosen years ago to satisfy one requirement. Either you are keeping material you should have deleted, or deleting material you are obliged to keep, and usually both in different channels.
The question arrives from legal, a customer or a regulator, and answering it means reconstructing channel membership at a past date from memory. The absence of that answer is itself the finding.
Salesforce and Slack enforce access in two different ways, and connecting them does not merge the models. Salesforce governs the record through profiles, permission sets and sharing rules; Slack governs the conversation through workspace, channel and app membership. Governance is the work of deciding how the two line up, and recording that decision.
What the platforms do. Salesforce controls who can act: a Slack user is mapped to a Salesforce user, and actions in the Salesforce apps run in that user's context under their own access rights, so a person cannot act on a record through Slack that they could not act on directly. An admin also controls how much record detail notifications carry. Slack controls who can see the conversation, and on its enterprise plans offers retention policies, legal hold and eDiscovery support, DLP through partner integrations, and key management as an add-on — availability depends on your plan and configuration, which we confirm rather than assume. Slack's own security documentation is here.
The gap between them. Neither platform governs what the other exposes. Slack does not know your sharing rules; Salesforce does not know who is in the channel. Every notification carrying record detail sits in that gap, which is why exposure is a design decision rather than a formatting one.
What Twopir does. We map identity properly, decide detail-per-channel deliberately, bound external collaboration, set retention against the obligation rather than a default, and leave you able to answer who could see what and when. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
The fourth column is the engagement. Everything in it is a decision someone has to take explicitly, because no default in either platform takes it for you.
| Control | Salesforce governs | Slack governs | Where they must be reconciled |
|---|---|---|---|
| Identity | The user, their profile and permission sets. | The member, their workspace and channel membership. | User mapping. Wrong or missing mapping means actions run in the wrong context, with no error raised. |
| Record access | Sharing rules, field-level security, object permissions. | Nothing. Slack has no concept of your sharing model. | Actions must run in the acting user's Salesforce context — never as a shared integration account. |
| Visibility of content | Who can open the record. | Who is in the channel where its detail was posted. | How much detail a notification carries per channel. This is an access decision, not a layout one. |
| External participants | Community and portal licences, sharing sets. | Guests and Slack Connect channels. | External people cannot join Salesforce channels, so customer-facing work needs a separate, governed Connect channel. |
| Retention | Field history, audit trail and org data policies. | Workspace and channel retention policies. | One obligation, two systems. Policies set independently will disagree, usually in the direction you least want. |
| Audit | Setup audit trail and field history. | Access logs and, on enterprise plans, eDiscovery export. | Answering 'who could see this record detail, and when' requires both sides and is rarely designed for. |
Control categories; specific Slack capabilities depend on plan and configuration
A narrow channel of named owners can carry amount and stage; a company-wide channel gets the fact and a link, with the detail left on the record where the sharing model still governs it. Salesforce provides a record-detail setting for notifications; the per-channel judgement is yours to make and ours to design.
Verified per user, re-verified after any app reconnection, and reviewed when people change role. A silent mapping error is an access error that raises no alarm, which makes periodic verification the only way to catch it.
Slack Connect channels created under an approval path with a naming convention, an owner and a review date, plus a maintained list of which outside organisations hold a live channel. External people cannot be invited into Salesforce channels, so this runs alongside rather than inside them.
Policies set per channel class against the actual legal and regulatory requirement rather than one global default, with legal hold and export paths tested before they are needed rather than during an incident.
Six workstreams. The first two produce the document most organisations discover they have never had.
Who is mapped to whom, which permission sets are assigned, which apps hold which scopes, and which channels carry record detail. The inventory is usually the first time anyone has seen all of it in one place.
A rule for how much record detail each class of channel may carry, applied to the notification design, so the question of what is safe to post has an answer that is not per-person judgement.
Mapping verified per user and tied to your existing starters and leavers process, so access in both systems changes when someone's role does rather than when someone remembers.
Approval, naming, ownership and review for Slack Connect channels and guest accounts, plus the maintained list of who currently has access from outside.
Retention per channel class set against the actual obligation, with legal hold and export paths tested rather than assumed. Availability of specific controls depends on your Slack plan, which we confirm first.
A documented model plus a rehearsed procedure for answering who could see what and when — the question that is expensive precisely because nobody prepared for it.
Four phases. Most organisations find phase one uncomfortable and phase four is what they actually wanted all along.
Mapping, permission sets, app scopes, channel membership on the channels that carry record detail, guests and live Connect channels. Read-only, and usually surprising.
The gap between the two is the finding. We produce it as a list with severity attached rather than as an opinion, so it can be prioritised against everything else you are doing.
Exposure rules per channel class, mapping verification built into joiner-mover-leaver, external collaboration under an approval path, retention set per obligation.
Who could see this, when, and who acted. A model nobody has tested against a real question is an assumption, and an incident is a poor time to discover which.
Delivered Slack engagements on Salesforce. The figures are the ones published on each case study, with their original scope intact.
The goal was never to replace Salesforce — it’s still the system of record. We just made sure the team never had to leave Slack to know what was happening in their pipeline.
Two of the six rollout problems found in testing were access problems: user mapping that sent notifications to the wrong people or nowhere, and missing permission sets that blocked users entirely. Both were corrected before go-live.
Client-facing channels and a mostly non-desk workforce on personal devices — a governance shape where who is in which channel is the whole control.
On the Sales Elevate engagement, permission sets were assigned so sales, pre-sales, managers, finance and customer success each had the access their role required — no more, no less. That is the governance outcome, not a side effect of the rollout.
Governance added after a system is in use is remediation, and remediation is always more expensive and less complete than design.
How much record detail a notification carries into a given channel is a permissions question, not a formatting one. Framing it correctly is most of the fix.
A silent mapping error grants the wrong context and raises no alarm. It is verified per user and re-verified after reconnection, because there is no other way to find it.
Several Slack enterprise controls are add-ons or plan-dependent. We confirm what you actually have before designing around it, rather than quoting a capability list back at you.
Slack Connect is genuinely useful and it is an access surface. Approval, naming, ownership and a maintained list of who is connected are cheap to set up and impossible to reconstruct later.
Who could see this, and when. A model nobody has tested against that question is an assumption, and you find out which during the incident.
Not for actions. A Slack user is mapped to a Salesforce user, and actions taken through the Salesforce apps run in that user's context under their own access rights, so someone cannot act on a record through Slack that they could not act on directly. What the model does not cover is visibility: record detail posted into a channel is seen by everyone in that channel regardless of your sharing rules. That gap is the thing to design for.
Yes, and it should be a deliberate decision rather than a default. Salesforce provides an admin setting controlling how much record detail is shared in notifications, and beyond that the design choice is what each class of channel may carry. Our usual pattern is that narrow channels of named owners can carry detail, while broad channels get the fact and a link, leaving the detail on the record where the sharing model still applies.
Everyone in that channel from both organisations, which is the point of it and also the risk. It needs an approval path, a naming convention, an owner and a review date, plus a maintained list of which external organisations currently hold a live channel. One constraint worth knowing early: external people cannot be invited into Salesforce channels specifically, so customer-facing collaboration runs in a Connect channel alongside the internal record channel rather than inside it.
On its enterprise plans Slack supports retention policies, legal hold and eDiscovery export, integrates with third-party DLP tools, and offers key management as an add-on. Availability varies by plan and several of these are not base features, so we confirm what your organisation actually has before designing around it rather than quoting the capability list.
Usually yes, and it is one of the quickest wins available. Apps hold the scopes they requested when they were installed, often years ago and often broader than anyone would approve today. An app and scope inventory is part of the access review, and the outcome is frequently a shorter list of installed apps rather than a new control.
Only if you designed for it. Answering properly needs both sides: Salesforce's audit trail and field history for who could open the record, and Slack's access logs and, on enterprise plans, eDiscovery export for who was in the channel. We document the model and rehearse the procedure, because the middle of an incident is the wrong time to find out which logs you do not have.
The design is a project; staying correct is ongoing. Access drifts as people change roles, apps get installed and channels get created, so the model needs a review cadence and mapping needs to be tied to your joiner-mover-leaver process. Some clients run that themselves after we design it; others include it in a managed service.
A governance review covers mapping, permission sets, app scopes, external channels and which channels currently carry record detail. You leave with the inventory and a severity-ranked gap list, whether or not you engage us to close it.
Access designed with the build, not after the audit
