Identity Access Management (IAM)

User Attribute Management in Trial Interactive IAM

Overview

The Trial Interactive platform consists of multiple applications that integrate with a centralized Identity and Access Management (IAM) system. A single user may be invited into multiple applications, domains, or rooms, each potentially managed by different administrators. Because user identity is shared and multiplexed across these contexts, changes to user attributes must be carefully controlled.

This document describes how user attributes are created and maintained over time, and which roles are permitted to modify them. The goal is to balance:

  • Operational needs, such as QMS, training, and job description alignment
  • Identity integrity, ensuring that core identity attributes remain consistent across clients
  • User ownership, allowing individuals to manage their own personal identity
  • Security and auditability, particularly for changes with authentication implications

User Attributes and Their Significance

Not all user attributes have the same impact:

  • Email is the primary identity credential in IAM and is globally unique. Changes affect authentication, authorization, and cross-application identity.
  • Name represents the user’s personal identity and is shared across all applications using IAM.
  • Title represents organizational context and is required for compliance-driven workflows such as QMS, training assignments, and job descriptions.
  • Other profile details (e.g., address) are user-owned metadata with no cross-tenant impact.

Because these attributes serve different purposes, they are governed by different update rules.

User Lifecycle Considerations

Brand New Users

A brand new user is one that does not yet exist in the central IAM system. At this point, there is no shared identity and no risk of conflicting administrative actions across clients.

For this reason, administrators are allowed to fully define the initial identity of a new user at creation time.

Existing Users

Once a user exists in IAM, their identity may be shared across multiple applications and organizations. At this stage, unrestricted administrative updates could lead to:

  • One client unintentionally changing identity details for another
  • Conflicting assumptions about user identity
  • Loss of user trust and ownership over personal information

As a result, update permissions become more restrictive after initial creation.

Role-Based Attribute Management

Admin

Admins operate at the application or tenant level and are responsible for managing users within their organizational and room context.

  • For brand new users, admins may set the email, name, and title as part of the initial invite or provisioning flow.
  • For existing users, admins may only update the title.

This exception for title exists because titles are required for QMS, training, and job description management, and must remain under administrative control. Admins are explicitly not allowed to change names or emails for existing users, as those attributes represent shared identity across clients.

Superadmin

Superadmins have elevated, platform-level authority and may correct or manage identity metadata when necessary.

  • Superadmins may update name and title for existing users.
  • Superadmins may not update email, as email changes have security and authentication implications that require specialized handling.

Solutions Engineer (SE)

Solutions Engineers are responsible for the integrity of the IAM system itself.

  • SEs are the only role permitted to change email addresses for existing users.
  • This ensures that email changes are handled centrally, with appropriate validation, auditing, and downstream synchronization.

User (Self-Service)

Users are allowed to manage their own personal profile information.

  • Users may update their name and other profile details.
  • Users may not update their email or title.
  • This model reinforces user ownership of identity while preserving organizational and security controls over sensitive attributes.

Key Principles

  • Shared identity requires centralized control: Attributes that affect authentication or cross-client identity are tightly governed.
  • Least privilege by default: Each role is granted only the authority required for its responsibilities.
  • Administrative authority is contextual: Tenant-level admins manage organizational metadata, not personal identity.
  • Users own their identity: Wherever possible, users control their own personal information.

This model allows the platform to meet compliance and operational needs while maintaining a consistent, trustworthy identity system across all applications.