#Slack Developers17 debatiendo

Hi @James K.k

The biggest win is usually reducing database operations, not just reducing Flow elements.

I’d bulkify the Flow around collections, eliminate Get Records/DML inside loops, and query only the fields/records actually needed. If the volume or logic still pushes governor limits, I’d move that part to Apex and let Flow handle the orchestration.

This is a standard multi-tenant integration problem, and the fix is to decouple "receiving the Slack event" from "which customer org owns it":

1. One shared gateway endpoint, not tied to any single customer's org — this can be a lightweight middleware/integration layer (or even a Salesforce org dedicated to this purpose) that owns the single Slack Request URL and does nothing except receive and route events.
2. A mapping table (Slack team_id → customer org connection details: instance URL, auth credentials/Named Credential reference) that the gateway looks up on every incoming event. Slack always sends team_id in the payload, so this is your routing key.
3. Outbound callout to the correct org, authenticated per customer — typically via a Named Credential (or OAuth JWT flow) configured per tenant, so the gateway calls each customer's org as an external system rather than the customer's org receiving Slack traffic directly.
4. Verify the Slack signature per request against the shared signing secret before you even look at the payload — since one endpoint now serves multiple tenants, this check is what prevents cross-tenant spoofing.

If you don't want to stand up separate middleware, you can implement the gateway as a small Salesforce org (or a lightweight Apex REST service in whichever org you already control) whose only job is to receive, authenticate, look up the tenant, and forward — keeping the actual business logic entirely inside each customer's own org. The two things that matter most in this shape (a single inbound entry point fanning out to multiple external systems based on a routing key) are keeping the routing/credential mapping data out of code (custom metadata or a protected custom object) and validating the source signature before any routing decision. 

Hey Maksimilian, 

 That error is the Apex SDK for Slack telling you your message-event handler threw an unhandled exception — it's coming from your Apex code, not Slack itself. That's also why it only happens on inbound Slack messages: sending from Salesforce never touches that handler, so nothing throws.

Turn on debug logs for the integration user and post one test message — the log will show the exact line that's null.

Usual causes:

• Message subtypes (bot messages, edits, thread replies, channel_join) hit the same handler but don't carry the same fields, so event.getUser()/getText() comes back null if you assume every message looks the same.
• A SOQL lookup by user/channel ID returning no rows, then grabbing [0] before checking.

Fix is null-guarding the handler itself — no need to touch scopes or event subscriptions. Happy to look at the handler class if you want to share it. 

This is a good point about the challenge of testing Slack + Salesforce integrations at enterprise scale. With an 8-member sandbox limit, using a combination of focused integration tests, representative test users, and staged UAT seems like a practical way to identify issues before production.

For smaller customization needs during UAT, tools such as espaço invisível para copiar e colar can also be useful when testing how different text formats, usernames, or messages behave across Slack and other platforms.

Hey Sebastien, 

Not a bug in your API usage, this is a genuine gap. The canvases.edit rename operation with title_content updates the canvas's underlying title, but Slack's channel canvas tab has a separate, independently-set "tab name" property. That tab name gets set once (typically when the canvas is first added to a tab) and doesn't automatically re-sync to the canvas title afterward, which matches exactly what you're seeing: manually clearing the tab name forces it to re-sync, but API-based title renames don't propagate to it. 

I couldn't find any Slack API method (canvases.edit, canvases.sections.lookup, conversations.canvases.create) that exposes or resets the tab name specifically, only the canvas title itself. So this looks like a genuine limitation, not something you're missing, there's no documented API method for touching the tab name independently. 

Worth filing this as a bug/feature request via Slack's developer support, since the manual "clear the tab name" workaround you found is really a UI-only re-sync trigger that has no API equivalent yet. 

Reference:

From what I've been seen so far, SlackCRM on Business+ V2 appears to require both the appropriate Slack subscription and compatible Salesforce licensing, but the publicly available documentation on the setup process and limitations seems quite limited.

For anyone planning a deployment, I would recommend verifying:

• Required Slack and Salesforce license types
• Admin permissions and authentication requirements
• Supported integration features on Business+ versus Enterprise Grid
• Sandbox and testing limitations
• Data retention, storage, and email-related constraints

If anyone from Slack or someone who has already implemented SlackCRM in production could share the official documentation or real-world experience, it would be extremely helpful for the community.

Hi there! Great questions, happy to help clarify what's available with the customer management feature in the new version of Slack Business+. 

Slack's built-in CRM tools let you build contact records, log customer interactions, and collaborate with your team — all within Slack. Under the hood, it relies on Salesforce Free Edition, which is automatically created when you set up a contact list.  

End-to-end setup process

• Click your profile picture → Preferences → Salesforce → Create New Salesforce Org
• This must be done by a Workspace Owner

Step 2 — Create your contact list 

• Import from Gmail, a CSV file, or build from scratch
• Access via: Home tab → Salesforce section in the sidebar → All Contacts

Step 3 — Assign access 

• Go to Admin → Manage Salesforce Organizations → select your org → Users tab → Add users to Salesforce org
• Up to 100 people can be granted access
• Permission levels are available via a drop-down menu

Key capabilities

• Log customer interactions (calls, emails, meetings) directly from a contact record 
• Share contacts in DMs or channels 
• Auto-sync Google Calendar and email events via Einstein Activity Capture 
• Customize contact fields (add priority, status, and more) 

Known limitations / constraints 

• Access is capped at 100 users
• Runs on Salesforce Free Edition — advanced Salesforce features/configurations beyond what's described in the help article are not part of this offering 

For the full setup walkthrough, check out the official help article: Manage customer contacts in Slack