Plan tenant setup and validate configuration changes
Tenant administrator or the delegated permissions for the particular Setup action. Some capabilities also require module activation and the applicable operating view.
A coherent tenant setup connects people, process conventions, service commitments and portal channels. The sequence below is recommended practice, not an automated provisioning wizard or universal Settings audit feature.
Before you start
Identify the tenant administrator, domain owners and platform-admin contact. Agree a representative Service, user roles and pilot journeys. Record existing values and review dependencies before changing an established tenant.
Steps
- Confirm tenant context, administrator access, operating view and platform-admin module activation.
- Establish Organizations, Keycloak-backed Teams and Users, then test membership, queues and denied access. If Entra SSO is required, separately enable the licensed module, configure mappings, complete the pilot tests and activate the connection before assuming Entra-managed group administration.
- Agree priorities, recurring schedules and domain-specific status conventions. Distinguish configurable lists from fixed task states.
- Define Services and usable default Offerings with assignment teams and realistic priority targets.
- Configure request/catalog approvals and Knowledge audience/publication, then submit sample requests and test published visibility.
- Configure Change and availability policies and test authorization, schedule restrictions and explicit Outage evidence.
- Introduce relevant Asset and Configuration Management functions with a small, reliable data scope.
- Configure branding, ServiceHub tiles and helpdesks. Validate normal-user intake, routing and team visibility.
- Record acceptance results, owners, exceptions and rollback decisions before wider adoption.
Configuration change record
For a material change retain setting, previous/new value, reason, requester/approver, date, affected Services/Teams, test outcome and rollback decision. Use an appropriate change record or governance tool where the application does not expose those fields.
Identity and notification acceptance
Verify Teams creation and membership against Keycloak in a local-managed tenant, and ensure an ACTIVE Entra connection prohibits structural changes while permitting Team application-specific fields. In PILOT, test restrictions on mapped teams. Test AgentHub's Microsoft 365 mailbox separately from outbound notification email, which may use O365/Graph, SMTP or an API delivery option, depending on the installed release and configured transport. Keycloak verification mail is a distinct mail flow. Do not infer successful delivery from a saved configuration or a successful API connection test.
Representative acceptance checks
Verify normal Offering routing and disabled CI override behaviour; in/out-of-hours clocks and organization handovers; restricted transitions and Change blackout handling; partial fulfilment and cancellation; ordinary-user/internal Knowledge visibility; asset-manager status-write denial; correct portal tile action; and cross-team helpdesk visibility boundaries.
Check a user with the intended restricted role as well as an administrator. A successful privileged operation alone does not demonstrate least-privilege access.
Troubleshooting
Missing gear or settings entry: inspect role, delegated scope, operating view and module activation. Rejected status save: check admin-write restrictions and validation. Unexpected routing: inspect default Offering, team and explicit CI/Instance override. Unexpected SLA: inspect priority, schedule and frozen measurement context. Wrong login logo: check image constraints and realm. Unexpected mailbox scope: inspect team/helpdesk mapping and account rights.
Expected result
Owners can demonstrate the intended business flows and explain the operational effect of significant settings changes.
Important behaviour
The documentation is grounded in design and implementation references, not a live tenant acceptance test. Confirm exact labels and action permissions in the deployed release. Tenant isolation and authorization are server-side responsibilities; hidden buttons are not the security boundary.