Check if the current user has a role in a Client Script

Client-side role checking with g_user.hasRole() is fundamentally about user experience, not security. The browser receives all role information when the page loads, making it perfect for conditional field display and form behavior, but completely useless as a security control. Every role check must be re-validated server-side in Business Rules, ACLs, or Script Includes because a user can modify client-side JavaScript at will. Think of this as the difference between hiding a door and locking it.

When to use this

• Show/hide fields or sections based on user roles for better UX
• Enable/disable form controls to guide user workflow
• Display different messages or help text for different role levels
• Control UI Actions visibility before they execute (still validate server-side)

When NOT to use this

• As your only security check — always implement ACLs or Business Rule validation
• In Service Portal — use gs.hasRole() server-side instead
• For checking inherited roles — use GlideUser server-side for complex role hierarchies
• When role membership changes frequently — client role cache may be stale

Key behaviors and gotchas

• Role checks are case-sensitive — hasRole('ADMIN') fails if role is admin
• Admin role bypasses all other role checks — hasRole('admin') returns true, others may too
• Returns boolean false for empty string, null, undefined, or non-existent roles
• Role data loads with the form — no async calls needed, but cache can be outdated
• Domain separation affects role visibility — users only see roles from accessible domains
• g_user.userID and g_user.userName provide sys_id and username for additional user context