Set workspace access policy¶

Draft guide. These steps follow the intended Tenant Admin Final Screens inspected on 6 October 2026. The frontend is still being built: its current policy page changes local preview values and simulates Settings saved without saving them to the service. Connected policy changes and environment availability have not been verified. This guide explains the intended journey and verified service behavior; it does not establish live availability.

Workspace access policy lets an administrator limit eligible email domains, require extra verification when people enter a workspace, and define working days and hours used for workflow timing. These settings affect different parts of the experience. A working-hours calendar does not establish a schedule that prevents people from signing in outside those hours.

The policy also contains activity-history retention and hold settings. Those controls, and holiday editing, are absent from the inspected screen. Their effects are explained below without inventing an editing journey.

Prepare the change¶

Use an eligible administrator account in the intended workspace. Review who could be affected, including other administrators, invited people and members returning after removal. An allowed email domain does not create an account, approve a join request, grant a product license or replace the person's other access requirements.

Before narrowing the domain list or requiring extra verification, arrange another administrator who can actually enter the workspace. The service's save safeguard checks administrator membership and email-domain eligibility; it does not prove that an account is usable or that the administrator can complete extra verification. Confirm those conditions separately.

Coordinate calendar changes with the people responsible for workflow deadlines. Working time is interpreted using the workspace's active headquarters time zone. It is not automatically based on the administrator's device or personal time zone. See branches and headquarters.

Open the policy¶

1. Open the intended workspace's Tenant Admin area.
2. Select Settings, then Access Policy.
3. Review Allowed Email Domains, Workspace Verification and Business Hours before changing anything.

The intended page includes a saved-policy summary. In the current preview, the domain count, policy version and saved date are sample values; they do not show a policy read from your workspace. Email Connector and Open shared work memory lead to separate settings and are not part of saving this policy.

Add an allowed email domain¶

1. Under Allowed Email Domains, review the existing list.
2. Enter the domain in the Add Domain field, for example example.com. Enter the domain rather than a person's full email address.
3. Select Add Domain and check that the intended domain appears in the list.
4. Continue reviewing the other sections, then use Save Changes for the complete policy.

Matching is exact and ignores letter case. Allowing example.com does not automatically allow department.example.com; include that domain separately if needed. The service normalizes domain spelling, removes duplicates and rejects invalid domain values. The current preview's local add action does not perform all of those checks.

An empty domain list removes this particular restriction. It does not let everyone enter: account, membership, verification, workspace and product access rules still apply. The inspected design and frontend show existing domain chips but no verified removal control. Domain removal and clearing the list need a completed interaction before a removal procedure can be documented.

Domain policy is checked during invitations, acceptance, join requests and approval, member reactivation, and workspace entry. It can also reject later requests using an existing workspace session. A person should not assume that having signed in earlier preserves access after the policy changes. There is no verified promise that every active session changes at exactly the same instant.

If a change would exclude every administrator identified by the domain safeguard, saving is rejected. Revise the domains and preserve an administrator's usable access. Do not treat this check as proof that every administrator can still sign in.

Require extra verification¶

1. Find Workspace Verification.
2. Set Require extra verification to the intended value.
3. Confirm that affected administrators and members can complete the workspace-entry verification process.
4. Include this choice when selecting Save Changes.

When this policy requires extra verification, workspace entry checks whether the sign-in already carries sufficient verification assurance. When it does not, the service starts the workspace verification step. Follow workspace switching and verification for that journey.

This setting is separate from a person's account-level verification preference. Turning off the workspace requirement does not establish that every other verification requirement is disabled. The domain-coverage message displayed near this setting does not verify readiness for extra verification.

Set working days, hours and breaks¶

1. Under Business Hours, expand the day you want to change.
2. Use Working Day to indicate whether that day contributes working time.
3. For a working day, choose Start Time and End Time, with the start earlier than the end. These screen instructions cover a schedule within one day; an overnight-shift editing journey has not been verified.
4. If the day has a break, turn on Include Break Time, adjust the break on the day's timeline and check the displayed Break Window. The break must start after the working day begins, end before it finishes and have an end later than its start.
5. Review every affected day, including days marked Not scheduled, then include the calendar in Save Changes.

The service uses working intervals, breaks and configured holidays when calculating workflow response, completion and escalation timing. For example, a two-hour target starting at 11:30 with a 12:00–13:00 break and sufficient afternoon working time finishes at 14:30. The break does not count toward those two hours.

Workflow timing needs at least one valid working day and a valid active-headquarters time zone. Although the general policy can represent all days as nonworking, that calendar cannot support these workflow calculations. Do not interpret acceptance of a policy as proof that every downstream use is ready.

Existing timed workflow tasks retain a calendar snapshot. The inspected resume path uses that saved calendar. Changing the workspace calendar does not establish that existing deadlines will be recalculated. Review active work with its owner when changing hours or holidays.

Save and verify the result¶

Save Changes is the intended final action after reviewing all sections. The current frontend only simulates success, and the design's save prototype leads to the workspace overview without a verified success or error companion. A success banner in this preview is not evidence of a saved workspace policy.

The current saving process also has unresolved limits: it would clear existing holidays because it does not include them, and it needs activity-history retention and hold values that this form does not collect. These gaps must be resolved before relying on this page to preserve the complete policy. If a workspace already has holiday or retention settings, have its administrator or support owner verify them through the supported operational process; do not use this preview as a production editor.

Once a connected implementation is available, confirm the saved result by reopening the policy and checking the actual stored values. Coordinate with other administrators: saving does not check whether your edits are based on the latest saved version. After an uncertain result, read the current settings before trying again.

Understand retention and holds¶

Activity-history retention determines which older activity records become eligible for scheduled removal. The service enforces a configured minimum when saving. Shortening the period can make more records eligible for the next retention run; changing the setting does not mean deletion has already completed. Extending retention does not restore records already removed.

A hold causes a matching activity-history retention run to skip deletion. A run checks the current policy and its version before it starts deleting; enabling a hold during a run does not guarantee that the running deletion stops. A policy change can also cause previously scheduled work to require operational follow-up. This is a specific behavior of activity-history processing, not a promise to retain every kind of information throughout the platform. Other data lifecycle paths require their own review.

There is no verified retention, hold or holiday editor in this Final Screen. These settings need an agreed administration journey and a complete save contract before user instructions can describe how to change them.

Help affected people recover¶

For support, provide the workspace, intended change, time and visible message. Never send passwords, session tokens or verification codes. For managers and business owners, agree who owns administrator continuity, calendar accuracy and retention decisions before rollout. Those responsibilities remain necessary even when the form can be saved successfully.