Understand Propagation after a deploy

Use this article to acquire the concept of eventual consistency and understand:

• How the Propagating status works.
• Which actions are blocked.
• When the tenant status returns to Ready.

Microsoft 365 applies configuration changes over time

Eventual consistency means that Microsoft accepts a configuration change before it has propagated across Microsoft 365 and before the updated information is visible in Configuration Resilience. While the status is "Propagating", Configuration Resilience may display data that has not yet been updated. Once the status is "Ready", the value shown in Configuration Resilience will match the updated value in the tenant.

Microsoft Entra, for example, uses a multi-region, multi-replica directory designed for scale, availability, and fault tolerance. When an object is created or updated, Microsoft accepts the write and then replicates it asynchronously across directory replicas.

Stages of a configuration change

1. Write accepted: Microsoft confirms the change to the caller, which is CoreView for a Configuration Resilience deploy.
2. Replication: Microsoft copies the change to replicas and dependent services in the background.
3. Converged: services and APIs return the new configuration.

Propagation time has no fixed duration

Microsoft does not publish a guaranteed propagation time. The delay varies by service, workload, and tenant. It is usually short, but it is not predictable.

Eventual consistency applies to all management interfaces

Eventual consistency applies regardless of the interface used, including Microsoft Graph and PowerShell. Changes made in Microsoft admin centers behave the same way.

Microsoft Graph documentation also notes that a newly created group can take time to replicate and that requests during that window can fail.

Tenant reads can return the previous configuration after a successful deploy

Configuration Resilience records a deploy as successful when Microsoft accepts the change. Replication across your tenant continues after that point and is outside CoreView’s control.

During propagation, tools that read the tenant can return the configuration from before the deploy:

• Backups taken on the scope can capture the pre-deploy state.
• Compare can show differences between the deployed configuration and the tenant.
• Monitoring can report drift on the scope that you changed.
• Microsoft admin centers can still display previous values.

Propagating identifies a scope that Microsoft is still updating

Propagating indicates that a deploy on a scope succeeded and that Microsoft is still applying the change to your tenant. CoreView uses this status to: 

• Distinguish normal propagation delay from a failed deploy.
• Prevent overlapping deploys on the same scope.

Deploy status sequence

1. Running deployment: CoreView writes your change to Microsoft 365. CoreView runs one deploy at a time per tenant.
2. Deploy completed: a record of the deployment is created in Deploy history. A notification confirms the deploy and states that Microsoft will propagate the changes to your tenant. 
3. Propagating: when the deploy is recorded as successful in Deploy history, the affected scope changes to Propagating.
4. Ready: when the scope’s Propagating time expires, the scope returns to Ready automatically and its actions become available again.

Actions blocked while a scope is Propagating

Propagating applies to the affected scope, not to the entire tenant. If you deploy a change to Conditional Access Policies, for example, only that scope is Propagating. 

During this time, some actions within that scope may be blocked to prevent overlapping deploys. You can continue working on other scopes in the same tenant:

Where Propagating status is displayed

CoreView marks a Propagating scope consistently and displays the banner: Microsoft is propagating changes on this scope to your tenant. 

You can find it in the following sections:

• Compare: a Propagating scope has a separate state. It is not shown as “Drifted” because propagation is an expected temporary state, not a divergence to investigate.
• Monitoring: a badge identifies Propagating scopes without requiring you to open each scope.

Propagating duration depends on the scope

Microsoft does not signal when propagation is complete, so CoreView cannot detect that point directly. Checking for an exact match between the tenant and the deployed change is also unreliable because another administrator might legitimately change the same configuration during that time.

CoreView therefore returns a scope to Ready based on time. Each scope has a fixed Propagating time based on the expected propagation delay of the Microsoft resources it contains:

• A scope uses the delay of its slowest resource, with a minimum of 5 minutes.
• A baseline uses the longest Propagating time among its scopes.

Propagating duration by security category

The following values apply to scopes managed with Application authentication, listed by security category:

Actions to take while a scope is Propagating

• Wait for Ready before acting on the same scope: you can work on other scopes in the tenant while the affected scope is Propagating.
• Treat Compare and drift results cautiously after a deploy: deployment results are not visible while the status is Propagating. In case of drift results, run them again only after the scope returns to Ready
• Investigate a difference that remains after “Ready”: check in the Deploy history if any skipped operation is flagged. If there is no skipped icon, wait for the next backup and run "Compare" again. If the difference persists after the following backup, contact CoreView Support and include the operation ID:
  1. Open Deploy history
  2. Select the skipped property value
  3. Open the “Details” tab to find the operation ID
  4. Click on the “Copy” icon next to the ID for easier reporting

Propagating status FAQs