Organizations and access

Understand the organization surface

Open an organization from Account home, or use its configured company sign-in directly at the workspace. The visible sidebar is computed from the organization's enabled capabilities and your effective claims; a missing destination usually means the capability is unavailable or your role does not include its required claim.

Home

Your assigned active work, seven-day schedule, requested reviews, delivery attention, and project list.

Inbox

Mentions, assignments, invitations, reviews, and delivery notifications.

People

Directory of current members, roles, and join dates.

Teams

Organization-owned groups with their own overview, assigned work, calendar, and chat. Personal time recording remains under Time.

Projects

Optional delivery spaces for Work, Code, reviews, pipelines, Packages, and project Knowledge.

Search

Authorization-filtered results across projects, work, Knowledge, packages, and code.

Work from Home and Inbox

1. Review assigned work.Home groups your active project work into Open, In progress, and Done lanes.
2. Move an item when its state changes.Drag it to a lane or use the accessible lane selector. The project workflow transition is saved; failures remain visible on Home.
3. Scan the next seven days.Upcoming organization and project events appear beside work attention.
4. Respond to review and delivery attention.Open requested pull-request reviews, failed or running pipelines, and due milestones from their cards.
5. Clear notifications.Open Inbox and choose a notification title to read its recorded event or mention revision. Choose Mark read explicitly; opening an item leaves it unread. The optional Open resource action opens current authorized content separately. Load older items when pagination is available. Use Inbox on Account home for notifications across your authorized organizations and account.

Personalize the lanes

Rename, reorder, or hide the three personal Home lanes. These preferences are stored for this account and organization in the current browser; they never modify a project's workflow.

Configure company sign-in

Organization administrators can add multiple OpenID Connect providers. Choose a generic issuer or Microsoft Entra ID with a specific tenant. Register the exact callback shown in the form as a web redirect in the provider application, then supply its client ID and secret. Secrets are write-only; rotating a secret requires another configuration test.

1. Choose admission.New connectors use invitation-only enrollment. You can instead admit every authenticated provider user or require selected claims. Admission determines who may join; it does not itself grant permission claims.
2. Map access explicitly.Match selected claim values to teams or exact, scoped role versions. Scalar and array values use exact comparisons: Any needs one selected value, All needs every selected value. No mapping expressions run. The profile fields email and email_verified cannot be used for admission, mapped permissions or assurance. Prefer Entra app roles; incomplete group claims deny affected decisions and Mozaic does not expand groups through Microsoft Graph.
3. Test, inspect and enable.Complete a real provider sign-in and inspect the redacted admission and mapping preview. Testing preserves your administrator session and enrolls no company member. Only the tested current configuration can be enabled; any edit disables it and invalidates its test.
4. Review identity policy.Choose independently whether ordinary Mozaic accounts may enter through invitations. Existing organizations continue accepting them until an administrator changes policy. Check that another working administrator path remains before changing access.

Provider-managed and manual grants retain separate provenance. Revalidation removes obsolete mapped grants while retaining independent manual grants. Suspension and failed admission block access regardless of remaining grants; automatic enrollment never reverses an explicit suspension.

Company members sign in at the organization workspace with the configured provider. They receive an identity and session for that organization only, even when their provider subject or email matches another organization or a personal account. Company identities have no independent Mozaic password, personal account linking, organization creation, or cross-organization contribution access.

Invitation-only sign-in sends a fresh proof to the invitation’s stored recipient address after provider authentication. Complete it in the original browser. A provider email claim, even a matching one, does not replace this proof. Treat both invitation and recipient-proof links as one-time secrets.

Set assurance for individual actions

Keep the server defaults or choose an organization-wide rule, then override individual reads, downloads, changes and administration actions. Permission claims are still required separately. Review each effective rule, its accepted MFA sources, maximum proof age and machine-access setting. Existing protected actions start with a 15-minute proof window; configurable ages range from one minute to 24 hours. Authentication and recovery configuration always requires MFA within at most 15 minutes.

Provider MFA is accepted only through configured, validated assurance signals with an explicitly confirmed authentication-time meaning. For Entra, select an authentication context and configure its Microsoft Conditional Access policy to actually require the intended assurance. A context identifier alone does not establish that policy. Provider MFA never substitutes for a local WebAuthn assertion when a review requires one.

Provider revalidation defaults to one hour and can range from 15 minutes to 24 hours, bounded by the session’s lifetime. Expiry requires a new provider round trip with current admission claims. An unavailable provider grants no grace period; upstream directory changes still depend on provider propagation. Disabling a connector, suspending a member or changing policy affects subsequent checks, including Git, packages, downloads and live connections.

Administrators may enable organization-bound authenticator or passkey fallback after company sign-in. Enrollment requires fresh provider authentication and proof of the new factor. Recovery codes replace only the second factor: they cannot bypass SSO, an expired provider check, or revoked company access.

When an action needs verification, keep its form open and complete the offered check. Mozaic polls the current action’s policy, refreshes the session state and retries once with normal authorization and conflict checks. Unsaved inputs remain in the original tab. A human credential cannot bypass these requirements by using a command-line protocol; unattended automation requires an explicitly authorized machine credential and an action that permits it.

Create and maintain a team

1. Set the identity.Enter a name and URL slug.
2. Explain the team's purpose.Write a rich description. Later edits preserve immutable description history.
3. Create the team.Open its slug-based detail URL and use Overview, Work, Calendar, or Chat. Each tab shows only content associated with the selected team.
4. Add existing members.Use the team overview, or go to Settings › Access › Teams and choose the team, then Add member. Only organization members not already on the team are offered.
5. Remove membership carefully.Choose the member and confirm removal. This changes team-derived authorization but does not delete the person's organization membership.

Team managers can edit the name and description in a dedicated form. Open description history when you need to review earlier text. With Manage roles, use the team access controls to assign an existing role at an explicit organization or project scope. Use Settings › Access › Assignments for exact-resource grants. Review the scope before granting access; membership alone does not grant organization administration.

Invite an organization member

1. Enter the email.Personal-account acceptance requires this verified address. Company sign-in instead proves the intended recipient through a separate one-time email challenge after provider authentication.
2. Select the exact role version.Choose a seeded or custom role version. Future edits to the role create another version rather than changing this invitation silently.
3. Optionally select a team.The invitee joins that team atomically with organization membership.
4. Issue the invitation.It expires after seven days. Copy the one-time invitation URL from the success receipt before leaving.
5. Track or revoke it.Pending invitations appear under Members. Revoke one that was sent to the wrong address or is no longer needed.

Change a member's organization role

1. Find the member.Load additional members if the organization is paginated.
2. Choose the role.Available seeded roles are Owner, Maintainer, Contributor, Auditor, and Billing manager; custom role versions may also be available.
3. Save against current state.The server verifies the current member version and prevents stale overwrites.
4. Review effective access.Team membership and scoped assignments can add claims beyond the organization role.

Self-demotion is rejected when it would leave the organization without another authorized administrator. Promote a second suitable member first.

Create a custom role version

1. Identity.Enter the role name, description, and immutable key.
2. Permissions.Select the grouped claims included in version 1. Claims are additive; a role cannot deny access granted by another assignment.
3. Review.Confirm the key and complete claim set, then create the immutable first version.
4. Revise later.The current editor creates a new version when you change the role name or description and preserves the existing claim set. Existing memberships and invitations continue pointing to their exact assigned version until changed.

Grant scoped role or stewardship

1. Choose the assignment kind.Use Scoped role for a role version or Resource stewardship for Owner/Maintainer responsibility.
2. Choose the subject.Assign to one user or a team.
3. Choose the scope.Select the entire organization, a project, or an exact resource type and UUID.
4. Review and create.The new authorization is additive and is evaluated with all other membership and team-derived assignments.
5. Remove when no longer required.Confirm removal from the assignment inventory; the audit record remains.

Move resources with an exact preview

Project managers can reorganize resources between two distinct projects in the same organization. Select a whole-project merge, one repository, one complete NuGet identity or one complete OCI repository identity. Destination access is checked independently; project settings, memberships, secrets and integrations are not copied.

1. Choose the exact scope.Destination projects and source identities come from bounded current inventories. Load another page when needed. A package move keeps its native registry namespace and all retained versions.
2. Review the preview.Inspect exact resource IDs, versions, containment generations, state hashes, effective visibility, access changes, path guidance and expiry. Resolve every returned dependency blocker. NPM, Maven and Debian lack transfer contributors and block a whole-project merge when present; inventories larger than 128 identities also block execution.
3. Acknowledge destination access.Project grants change to the destination scope; exact-resource grants remain exact. Explicitly confirm the reviewed inventory, then complete fresh MFA when prompted. Changing the selection discards its preview and acknowledgement.
4. Recover the exact receipt.After an uncertain response, retry the retained command instead of creating another transfer. Stale or expired evidence requires a new preview and review before a new command. At most 32 pending previews per actor and 128 per organization are admitted; wait for expiry if that limit is reached.

A completed merge leaves a reloadable read-only source notice with its recorded operation and, when independently readable, its direct destination. Later destination merges are not followed automatically. Historical pipeline runs retain their original project and are not redirected. An individual move leaves the source active. Native UUID client endpoints, Git history, review snapshots and publication provenance retain their identities.

Issue and revoke an organization API token

An API token belongs to you as a human member and to the immutable organization shown in the workspace. It is not a service account and cannot outlive your membership or current effective authorization.

1. Name the use.Use a recognizable purpose such as one-off backlog import, then choose an expiry from 1 through 365 days.
2. Select the narrow scopes.Manage projects permits supported project listing and creation. Manage work permits supported work-item, milestone, board, assignment, and relation operations. You can select only capabilities your current access grants.
3. Confirm with fresh MFA.Issuance requires a normal browser session and fresh WebAuthn or TOTP authentication. API bearer authentication cannot issue another token.
4. Store the secret once.Copy the raw token from the issuance receipt into the calling process's secret store. Mozaic stores only a hash and cannot show the token again.
5. Verify, then revoke.After a one-off integration has reconciled its results, return to API tokens and revoke it with fresh MFA. Revocation is immediate and the metadata and audit evidence remain.

Every API request re-evaluates your live organization membership and roles in addition to the token's selected scope. Removing your membership, removing a needed claim, expiry, or revocation can therefore stop the token immediately. The bearer works only on the explicitly supported Project and Work JSON endpoints; it never authenticates Git, LFS, NuGet, operator, account, or realtime endpoints. Because bearer authentication is not cookie authentication, it does not use CSRF. The browser interface continues to use its secure session cookie and CSRF protections.

Inspect the audit trail

Browse immutable events, load older results, and open an event to inspect its structured detail. Use the actor, resource, action, and recorded payload to understand sensitive membership, role, visibility, moderation, and stewardship changes.

Empty states, conflicts, and access failures

• People is a directory, not the place to mutate access.
• Team removal does not remove organization membership.
• Role versions and audit events are immutable.
• Home-lane preferences are browser-local and personal.

Find people and authorized resources

Use the member directory

People lists current organization members with their organization role and join date. Use it to identify collaborators; access mutations remain in Settings › Access. If you can manage access, the directory provides a direct route there.

Search this organization

1. Enter a focused term.Search covers projects, repositories/code, work items, packages, and Knowledge in project contexts you may read.
2. Use the result type.Each result identifies its resource kind and opens its canonical authorized destination.
3. Search more project contexts.If the organization has more projects than the first loaded page, choose Search more project contexts to extend the same query.
4. Treat an empty result carefully.No authorized results means no match was found in the contexts searched and visible to you; it does not disclose whether a private resource exists elsewhere.