Skip to main content
bjoern_schulze
bjoern_schulze
Helper ⭐️⭐️⭐️
Oct 9, 2026 11:30 PM UTC
Question

Server-side Primary Role authorization for connectors

We are building custom Community widgets with role-based visibility. Our widgets check the viewer’s Primary Role before loading their content modules, but we also need server-side authorization to prevent unauthorized users from calling the connectors directly.

Does Developer Studio support a server-enforced Primary Role allowlist per connector, rejecting unauthorized requests before the upstream API call? The documented template user context exposes identity but not Primary Role. Is there a supported authorization mechanism or conditional authorization step for composite connectors?

Separately, does segment-based Widget Visibility prevent custom-widget scripts from loading and init()from running, or does it only hide the widget?

3 replies

samanthahamlet
samanthahamlet
Gainsight Community Manager
Oct 13, 2026 1:28 PM UTC

Hey ​@bjoern_schulze 

Checking internally for this one, will let you know as soon as I have an update! 😊

Translate
marekkoszlak
Gainsight Employee ⭐️
marekkoszlak
Gainsight Employee ⭐️
Oct 27, 2026 3:43 PM UTC

I checked this with our developers. There’s no server-enforced Primary Role allowlist for connectors today, and the user context in connector templates doesn’t include Primary Role (or other roles and segments). Composite connectors could technically work as a workaround, but aren’t a supported answer either. Our developers see this as a gap that should be eventually solved in the product and think the check should happen before a connector call goes out.

Segment visibility controls what members see, it isn’t an access control. A useful way to think about this is it’s meant to be used for managing visibility, rather than security.

We’ll evaluate this enhancement as a roadmap candidate, nothing to share on timelines yet. Is Primary Role the only thing you’d need to check on, or also custom roles and segments?

Translate
    bjoern_schulze
    bjoern_schulzeAuthor
    Helper ⭐️⭐️⭐️
    Oct 28, 2026 5:19 PM UTC

    Thanks for your detailled response! :)

    Our developers see this as a gap that should be eventually solved in the product and think the check should happen before a connector call goes out.

    I agree. A functionality like this would be globally beneficial to all the widgets and enhancements we can now work on thanks to the Developer Portal etc., as personalization will be a big factor in configuring the platform to its users’ needs (and permissions).

    Segment visibility controls what members see, it isn’t an access control. A useful way to think about this is it’s meant to be used for managing visibility, rather than security.

    Yes, I understand, and that’s exactly what I wanted to bring up.

    Is Primary Role the only thing you’d need to check on, or also custom roles and segments?

    I believe on a global scale any functionality that creates “user buckets” is relevant here:

    • Primary Roles - e.g. for creating widgets limited to super users or moderators
    • Custom Roles - e.g. for creating widgets limited to users with certain tasks / permissions / responsibilities on the platform
    • Segments (more for visibility, less for security) - e.g. for creating widgets targeted at users with certain activity stats or profile information 
    Translate
    Terms & ConditionsAccessibility statement