User Account
What It Is
A user account represents a person’s membership within a particular part of Rhythm. Console membership belongs to a customer, portal membership belongs to a workspace, and Rhythm staff use membership under Rhythm’s own customer. The account connects sign-in identities, profile information, membership standing and the access assigned to that person.
Access definitions and assignments are facets of this concept. A role names a reusable collection of policies and permission rules; a grant connects that definition to a subject, scope and validity period. Staff customer entry has an additional record explaining consent, standing authority or emergency use. Those records explain an account’s authority without creating separate broad product concepts.
The account can exist before usable sign-in or access. An invitation establishes a pending membership and offers assignments for acceptance. Portal registration follows its own confirmation path. An ended membership can still need readable attribution in earlier activity, so historical identity and present access have different responsibilities.
What It Is Not
An account differs from the CRM contact describing a person known to an association. A contact can exist without sign-in, while a portal account can link to that contact. Membership also differs from authority: owning an account or defining a role does not by itself establish usable permissions. Registered service principals identify machine callers separately from human membership.
How It Is Used
Customer administrators invite colleagues, maintain profiles and review assignments. They work with role and policy definitions when standard access does not fit a local job. Membership controls support temporary interruption, return and permanent removal. History and access explanations help them understand both recorded changes and currently evaluated authority.
People accept invitations, authenticate and recover their sign-in. The console reads evaluated access to organize their work. Portal members can connect their membership to CRM records. Staff administer their own memberships through HQ and use customer-entry records when their work requires a customer workspace. These activities remain subject to the rules in their respective capabilities.
Its Facets
Boundary and status. The membership’s wall identifies its customer or workspace. Account status distinguishes invited, active, suspended and revoked membership. Invitation delivery and sign-in identities explain entry; profile fields support names, dates and presentation. Former-user records retain names after deletion, and founding staff support initial administration.
Contact and machine identity. A linked contact connects portal work to association records. A service principal supplies a separate machine identity for attribution and status control.
Access definitions. Permissions and their released catalog provide the vocabulary for application actions. Policies group allow, deny and condition rules. Built-in policies and roles supply shared definitions; custom policies and roles represent customer jobs. The grants-nothing indication describes empty effective access, while an eligibility binding connects a custom role to source-managed qualification.
Assignments. Scope, grant state, time windows and conditions describe where and when a role counts. Automatic grants retain their derivation. Widening and last-administrator safeguards govern delegation. The security context describes evaluated access, and security history supports review of changes and recorded refusals.
Staff entry. Approved access follows a customer decision; given access begins with the customer’s initiative. Emergency access and standing access have distinct bases. A request records an undecided proposal, the emergency report supports review, and staff roles describe HQ authority separately from customer entry.
How It Relates
Customers own console memberships and customer access definitions. Workspaces own portal memberships and locate workspace-scoped assignments. A CRM contact supplies the person behind linked portal work and contact-based derivations. Staff-entry records retain the staff account as actor while applying a customer-appropriate role assignment. Released applications define the permissions used in those roles.
What It Could Become
The product should resolve the subject model for automatic grants and complete the associated editor experience. Deferred authentication extensions, staff multi-factor requirements and service-principal screens need explicit decisions. Access reviews should clearly distinguish manual, derived, approved, emergency and standing authority, and explain the accepted cache limit when authority changes.