Enterprise networks and linked workspaces¶
Draft documentation. Enterprise administration has backend support, while the inspected Tenant Admin frontend uses preview records and navigation in place of connected actions. A working deployment and reader acceptance have not been verified. Cross-workspace trust, exchange and catalog processing still require further reconciliation before this feature is complete.
An enterprise network connects workspaces that need shared administration and coordinated collaboration. Each workspace keeps its own identity. The network records which workspaces are linked, who holds enterprise roles, how governance responsibilities are arranged, and who owns particular commercial decisions.
A network link does not make every member an enterprise administrator or give everyone access to every linked workspace's information. Membership, product access, permissions, commercial eligibility and the rules for the particular collaboration still matter. Use the task guide for the intended administration journey.
What the network organizes¶
| Area | What it explains |
|---|---|
| Network identity | The enterprise name, network link and founding workspace |
| Linked workspaces | Which workspaces have joined and their current connection, sharing, governance and commercial settings |
| Invitations | Offers to join, their sender, expiry, response and any reason acceptance is unavailable |
| Network roles | Named responsibilities assigned through a person's membership in a linked workspace |
| Governance | Supported areas of shared guidance or requirements, currently Security and Branding |
| Commercial ownership | Who handles invoices, plan changes, seats, storage, premium access and upgrade approval for each linked workspace |
| Audit detail | A recorded decision associated with a selected shared exchange or published item |
Linking workspaces, buying a commercial offering and authorizing an individual exchange are separate decisions. An invitation acceptance is not a completed purchase, an approved exchange or permission to disclose all workspace content.
Before an organization starts¶
An eligible workspace administrator can create a network when the founding workspace supports enterprise federation and is not already linked to an enterprise. The backend checks the actual plan entitlement. The intended screens describe this as Premium or higher; a plan's displayed name alone is not proof of eligibility.
Creation adds the founding workspace to the network and gives the founding administrator an Owner assignment tied to their workspace membership. Choose a recognizable enterprise name and a suitable network link. Network links must be unique; retain the value returned by the service after creation.
A workspace can instead accept an invitation from an existing network. It cannot use that acceptance to join a different enterprise while already linked elsewhere. Decide which organizational relationship is intended before accepting or creating a network.
Invitations and membership¶
A network manager invites a particular workspace. The recipient's authorized administrator reviews and accepts or rejects the invitation. Sending an invitation does not itself add the workspace to the linked directory.
New invitations have a fourteen-day window in the inspected backend. Always use the expiry shown for the actual invitation. An expired or already answered invitation cannot be answered again through the normal pending-invitation operation. A new invitation may be needed after expiry, subject to the current eligibility and duplicate checks.
Acceptance records the selected invitation's response and creates the workspace link if it is missing. An existing link to that same enterprise is reused. Other network invitations are not automatically marked rejected or cancelled by that operation. Once the workspace belongs to an enterprise, another enterprise's pending invitation can remain on record while acceptance is blocked by the existing relationship.
Rejecting a pending invitation leaves the workspace unlinked by that invitation. Rejection does not require buying federation eligibility. If an invitation is unexpected, verify the network and sender with your organization before acting.
People and responsibilities¶
The available role names are Owner, Network admin, Governance admin, Billing admin, Catalog admin, Auditor and Partner manager. These names describe responsibilities; they do not make every person able to perform every enterprise operation.
Invitation and role management require an eligible workspace administrator who also has the required active enterprise management role. Governance and commercial changes have their own role checks. A job title, a displayed badge or an invitation alone does not grant that authority.
Enterprise role assignments are anchored to a person's membership in a linked workspace. Removing an assignment makes it inactive and preserves its history. It does not delete the person's account, remove their ordinary workspace membership or erase their work. The inspected role-removal journey has no restore action.
Understand lists and availability¶
An invitation can remain visible after it expires. Visibility or a count beside an invitation list does not mean every listed invitation can still be accepted. Check the selected invitation's state, expiry and workspace relationship. If an available action and a blocking message disagree, refresh the details and ask the responsible administrator or support team to resolve the discrepancy before relying on the result.
Broad workspace search returns at most 25 matches. Absence from those results does not prove that a workspace does not exist. The intended invitation guide uses the exact workspace slug to identify the target. A result still needs the normal identity, relationship and eligibility checks before an invitation can be sent.
Member counts reflect the selected search and activity filters. Inactive members may appear when an active-only filter is not applied; a visible name does not mean the person can receive a role. Someone eligible for another enterprise role may already hold the particular role you selected. Review the saved assignments after making a change.
An eligible workspace administrator can read commercial responsibilities for linked workspaces without being allowed to edit them. Changes additionally require the appropriate enterprise role. A displayed edit or eligibility indicator reflects a current assessment; it does not reserve authority or guarantee that a later action will succeed.
Governance and commercial decisions¶
Governance describes supported areas such as Security and Branding. An area can be disabled, advisory or required. The overall posture is derived from those choices: local control, an enterprise baseline with advisory guidance, or required areas. The phrase “Required domains” refers to governance areas; use workspace access policy for the separate email-domain and sign-in policy.
Commercial ownership is recorded separately for six decisions. A workspace can retain all responsibilities, the enterprise can own them, or responsibility can be split. Changing those owners does not itself buy seats, add storage, change a subscription or complete a payment. Follow Billing for an actual purchase or plan change.
Commercial offerings may require a priced contract item or an existing parent offering. A visible offering is not a quote or a guarantee that checkout is ready. Use the current readiness and blocking information for the selected workspace; do not rely on the sample values in a design or preview.
Read commercial readiness correctly¶
Commercial information combines the current subscription, workspace billing profile, plan catalog and enterprise relationship. An offering can be active in the subscription while a further purchase is unavailable. Treat these as separate questions:
| Question | What to verify |
|---|---|
| Does the workspace already have the offering? | The current subscription's commercial items |
| Is another purchase eligible? | The actual plan and any required parent offering |
| Can checkout start? | The available purchase path and, for recurring offerings, an active contract item with a positive price |
| Has the purchase taken effect? | The Billing workflow outcome and current subscription or allocation |
An enterprise plan upgrade shown here uses the self-service plan selection. Quote-only plans are not selected for that upgrade offer. The commercial summary is not a final price or an authorization to buy; the Billing journey supplies the actual purchase checks. If “active” and purchase readiness differ, ask the responsible administrator to review the contract and plan rather than repeatedly trying checkout.
Plan changes and the network link¶
When federation is unavailable, review the workspace's actual eligible plan options with its administrator. The current backend identifies the missing federation capability; it does not establish that every plan named Premium qualifies. An invitation to another workspace depends on that target workspace's eligibility, so changing the sender's plan alone does not resolve a target restriction.
An applied plan change can place an existing enterprise link on hold when the new plan lacks federation, or clear that link's hold when eligibility returns. The link is retained with its recorded governance, commercial responsibilities and sharing settings. This is separate from pausing the whole workspace, restoring a person's access or approving an individual exchange. Confirm the applied plan and current relationship before relying on collaboration; a saved checkout or closed payment page is insufficient. Plan changes explains the commercial lifecycle, and workspace recovery explains the separate pause/recovery process.
Collaboration beyond the network directory¶
The backend also contains publication records, sharing policies, partner relationships and exchange processing. These serve different purposes: a publication describes something offered for collaboration; a sharing policy describes permitted interactions; a partner relationship describes an organizational connection; an exchange is a particular piece of work. One record does not establish that every other condition has been met.
The inspected implementation does not expose connected setup actions for publishing catalog items, editing these trust policies, publishing shared service offerings or creating partner treaties. Do not treat those backend components as available administration tasks or infer a setup screen. Their entry points, authority and delivery need further work before a user guide can promise them.
Plan and policy changes also reach collaboration services through background messages. A network or commercial label alone does not prove that a particular exchange is currently allowed. If a recent change and a collaboration decision disagree, provide the workspace, reference and time to authorized support. Support must inspect the actual decision and its owning service; retrying an unrelated network action does not reconcile it.
Export, deletion and shared history¶
Shared enterprise records can concern more than one workspace. The inspected export and deletion handling covers records used to track and verify published collaboration contributions. It does not erase the shared network catalog, trust policies, partner records, exchanges, collaboration history or audit records.
The main export and deletion process does not currently count completion messages from Enterprise Collaboration. Its contribution data is therefore not added to the export package through those messages, and completion of the main process does not prove that deletion in this service finished.
Before relying on an enterprise export or deletion outcome, ask authorized support to confirm the requested data scope and the service-specific result. A zero “retained” count from this local operation does not count shared records that were outside the operation. No retention period, complete erasure guarantee or approved retention policy is established by this draft.
What business readers should agree¶
Executives and organizational owners should agree the founding workspace, which organizations may join, who may manage the network, and who takes responsibility for each commercial decision. Managers should identify the people who will act and confirm their actual workspace and enterprise authority. Members and external participants should use their normal administrator or support contact when a relationship or access decision is unclear.
Before relying on an enterprise relationship, confirm the relevant collaboration capability, its commercial eligibility and the rules for the intended work. A network summary is not a certification, an organization-wide data-sharing agreement or evidence that all integrations are ready.
Availability and limits¶
The intended Final Screens cover enterprise entry, linked workspaces, invitations, roles, governance, commercial profiles and individual audit details. Their current navigation and several examples need the recorded design follow-up. The frontend preview does not persist the enterprise actions described here.
Application delivery and a connected enterprise-administration workflow need separate verification in the environment you use. This draft does not establish live delivery. Until a connected experience is verified, arrange real changes through your organization's authorized support process.
The complete exchange, governed-AI and operational behavior inventory remains in progress. The internal integration reference records the inspected trust/publication boundaries, unresolved authority and plan-consistency constraints, and unfinished scope. This page is a reader draft, not whole-feature acceptance.