Skip to content

Members & team access

Members are the people who belong to a Platform Organization.

Organization membership connects a person’s Comers identity with the customer context they are allowed to enter.

Member management always belongs to an Organization.

Before adding or changing a member, select the intended Organization in Start. If the current account belongs to several Organizations, confirm the scope before continuing.

The current Start customer interface supports two member-creation paths.

Use Add by email when the person already has a Comers account.

Provide the account email and choose the membership role. Start links that existing identity with the selected Organization.

The same Comers identity can therefore belong to several Organizations without creating a separate login for each one.

Use Create user when the person does not yet have the required Comers identity.

The current Start flow can create the identity and Organization membership together. It collects the user profile and initial credential information required by this provisioning flow and can mark the initial password as temporary so the person must change it.

This is direct user and membership provisioning in the current customer Start interface.

Comers also has invitation concepts in its broader IAM architecture, but the current customer Start member screen does not expose a separate pending email-invitation workflow.

For customer Organizations, the visible Start actions are currently:

  • add an existing account by email,
  • create a new user and add that user.

Document the workflow you see in Start rather than assuming an email invitation is pending.

The current customer Organization role choices are:

  • owner,
  • member.

A role describes the membership, but effective permissions still control sensitive Platform operations.

For example, member management itself requires the relevant Organization permission.

Open a member record to review identity and profile information.

Depending on your access, you can change:

  • display name,
  • email,
  • username,
  • membership role.

The identity details shown by Start also include technical identity references. These help identify the linked account but are not values a normal operator should need to invent.

Removing a member deactivates their future membership in the selected Organization.

It should not erase historical attribution for actions the person performed previously.

Removing somebody from Organization A does not automatically remove their access to another Organization where they have an independent membership.

Keep three layers separate:

flowchart TD
    A[Comers account] --> M[Platform Organization membership]
    M --> P[Platform permissions]
    M --> C[Core identity projection]
    C --> O[Core operational permissions]

Platform membership controls the customer’s account-level relationship with the Organization.

After Core launch/enrollment, Core IAM controls operational access inside Core.

A Platform owner/member label should not be treated as a shortcut for every Core module permission.

See Team & permissions.

When adding people:

  1. select the correct Organization,
  2. reuse an existing Comers account when one already exists,
  3. grant the minimum appropriate membership role,
  4. configure operational Core access according to the person’s responsibility,
  5. remove access when the person no longer needs it.