Skip to main content

Anyone using Slack v2 with HRIS-driven provisioning + user mapping?

  • May 8, 2026
  • 2 replies
  • 116 views
Mirza
Contributor II
Forum|alt.badge.img+1

Curious if anyone has successfully implemented the native Slack v2 where:

  • An HRIS is their source of truth
  • Users are created & managed in Docebo via an integration (Docebo Connect, Workato, APIs, etc.)
  • Slack v2 is configured using User Mapping (not provisioning)
  • Username is the primary identifier used between Slack and Docebo and is identical in both systems

We’re trying to better understand how others are operationalizing synchronization in this kind of setup as i’m not finding it feasible and too risky based on available options.

Specifically, we’re seeing that the automatic synchronization behavior appears tied to Slack-side events (not what we want). Our concern is ensuring users created/updated from the HRIS flow into Slack mapping reliably and consistently before downstream notifications/events occur. The manual synchronization option is just not feasible nor scalable mid-size to large orgs. 

A few questions for anyone actively using this setup:

  1. Have you found the native Slack v2 synchronization reliable in this architecture?
  2. Are you supplementing it with Docebo Connect/custom automation/processes?
  3. Have you run into any user mapping timing or synchronization gaps?
  4. If so, what solutions or workarounds have worked best for you?


Docebo KB for Slack v2: https://help.docebo.com/hc/en-us/articles/30027366503954-Docebo-for-Slack-version-2

2 replies

Jason Kocur
Helper I
Forum|alt.badge.img+1
  • Jason Kocur
  • Helper I
  • September 2, 2026

Hi ​@Mirza 

Have you found any solutions here? We are starting to enable the Slack V2, but we are having an issue with the mapping method. I’ve published an idea that would allow us to only map against a specific Docebo branch as that would solve our primary issue of using email address. Looking for any other insights. 

Slack V2 - Mapping Idea: 

Thank You! 

Jason

Mirza
Contributor II
Forum|alt.badge.img+1
  • Mirza
  • Author
  • Contributor II
  • September 2, 2026

Hey ​@Jason Kocur  appreciate you reaching out.

I reviewed your idea and upvoted it as well. Your use case is a little different from what we’re seeing but I think we’re both running into the same broader issue with Slack v2: admins don’t have enough visibility or control over user mappings.

For me, the bigger concern I see is visibility. Before rolling this out, I need to be able to confirm that a Docebo user is mapped to the correct Slack user - for example, Suzie A is mapped to Suzie A and not Suzie B, John A, or another account. Without that, it’s hard to trust downstream Slack notifications, especially at companies with thousands of users and have compliance requirements for comms.

Docebo confirmed there currently isn’t an easy way to view these mappings, which is a pretty big gap given v2 was supposed to be an improvement over v1.

One workaround I was considering is connecting Slack v2 in Docebo to a Slack sandbox replica of production, send broad test notifications there to everyone (it wouldn’t go to anyone in production), and use that to validate mappings before enabling anything in production. I’m not sure yet whether that could give us visibility into mappings, at least on the slack side, so I want to check with a slack admin to confirm. 

If that works, it would remove one of the bigger risks from my rollout checklist. If not, I’m not comfortable enabling this in production for ~20K users. I also spoke with another Docebo customer with a smaller user base and they confirmed similar limitations and occasional mapping issues.

So I definitely agree with your idea, and more broadly, I think Docebo needs to provide better admin visibility and control over mappings.

Terms & ConditionsAccessibility statement