Configure approvals, maintenance and availability policies
Tenant administrator or the delegated permissions for the particular Setup action. Some capabilities also require module activation and the applicable operating view.
Approval, routing, maintenance and availability rules combine differently. Do not apply one universal inheritance rule to every setting.
Before you start
Identify the governing process, Service/Offering, technical targets and policy scope. Use the appropriate administrator rights and confirm which controls are exposed in the current tenant release.
Steps
- In the Change settings and relevant policy views, review required approvals, eligible approvers and CAB options where enabled.
- Test a Normal Change requiring review. Confirm the Change's own approval and transition guards rather than relying on a configured policy or linked Request alone.
- Review all applicable REQUIRED maintenance windows. The proposed interval must satisfy every required constraint.
- Check applicable blackouts, which accumulate. Test supported emergency exceptions separately with their required conditions and justification.
- For availability, inspect the configured policy at Offering, Service and tenant scope, and verify the selected target and committed schedule.
- Record a controlled explicit Outage with observed timing and review the resulting availability under the intended policy.
- Retain the test evidence, including refused operations and any known calculation limitations.
Compare resolution rules
Normal Incident team resolution uses an explicit enabled Primary-CI override, then an enabled one-hop parent Instance override, then the Offering team. This differs from multi-hop dependency-impact analysis.
Availability-policy precedence is Offering → Service → tenant default. Required maintenance windows combine as an intersection. Blackout restrictions accumulate. Offering SLA target context is copied into an Incident measurement at its start. Organization SLA uses separate organization-team-based timing.
Evidence and interpretation
An Outage is actual unavailability/degradation evidence, not an automatic consequence of creating an Incident. A maintenance window does not establish that disruption occurred. Availability reporting must state target, period and schedule; overlap can overcount, redundant/quorum descendants are excluded from documented propagation and full Offering-wide aggregation is not established.
Expected result
Approvals and schedules work according to their own rules, and reporting is traceable to a policy and observed evidence.
Important behaviour
Some policies are maintained on the Service/Offering or other domain screens rather than one universal Setup tab. Configuration does not itself authorize an individual Change or create missing Outage records.