Why does gs.hasRole() return different results in Background Script and ACL?

[PurnaChandM]

Hello everyone,

I am trying to understand the behavior of gs.hasRole() in different execution contexts.

I am using the Australia release and have created a custom role with:

• Display Name: Intake Agent
• Internal Name: intake_agent

This role is assigned to the integration user that calls my inbound Scripted REST API.

In a Background Script, both of the following return true:

         gs.hasRole("Intake Agent") -> true
         gs.hasRole("intake_agent") -> true

However, in the ACL used for my Scripted REST API, I get different results.

        gs.hasRole("Intake Agent") -> false
        gs.hasRole("intake_agent") -> true

The same integration user is used in both tests, and I am not impersonating any user.

I would like to understand:

• Is this expected behavior?
• Does gs.hasRole() only work with the internal role name inside ACLs?
• Why does the display name work in a Background Script but not in the ACL?
• Is there any documentation explaining this behavior?

I'm looking to understand the platform behavior rather than just using the internal role name as a workaround.

Any guidance would be greatly appreciated. Thank you!

If this query of mine let you to discover something new please mark this as helfful. 

[dimi_]

Looks like it's just the way it is. Passing the backend value and not the display name is always the best practice though. I guess the background script logic is more forgiving and search also for display name.

[abirakundu23]

Hi @PurnaChandM ,

ACLs always evaluate the internal role name (backend name) when executing access control logic. Using the internal role name is the recommended best practice, as display names should not be relied upon.

However, display label (for example, Intake Agent) return true using Background Scripts, this behavior is not documented.

Please mark helpful & correct answer if it's worthy for you.

[PurnaChandM]

Thank you for your response.

One point I'd like to clarify is that the internal name I mentioned in my question is not actually present in the sys_user_role table. I only created a role with the name "Intake Agent" and did not manually create or specify an internal/backend name.

When I query the sys_user_role table by name, it only returns "Intake Agent". I assumed "intake_agent" was the internal/backend name because gs.hasRole("intake_agent") returns true, but I don't see that value stored anywhere in the role record.

Could you please clarify where "intake_agent" is derived from and how gs.hasRole() resolves it? That's the part I'm trying to understand.

[dimi_]

While the suffix can contain spaces, the name in the database should not, but I just tested it and you are right, the system gives you the option to include spaces. That doesn't align with best practices, and will cause issues like the one you described though.