Progressive scanning
AI summary
Rencore Governance now scans more efficiently by processing and finalizing data in batches throughout each scan rather than only at the end, giving you more up-to-date inventory data and faster policy violation updates. Automations on policy violations trigger multiple times per day with daily thresholds. If you use these automations, verify your thresholds fit a daily limit.
Based on your feedback, we changed how quickly your Inventory objectsInventory objectAn inventory object is one item Rencore Governance has scanned from a connector, such as a single Team, SharePoint site collection, user or Power App.Read more are updated, Policy violationsViolationA violation is an inventory object that matches the rule of an active policy, such as a Team with no owner.Read more are triggered, and Automation thresholdsAutomation thresholdAn automation threshold, or threshold limit, caps how many objects an automation processes in one day.Read more work. This notice announced the change in 2025. It has since rolled out to all customers and is kept as a record. Progressive scanning is now how Rencore Governance scans. For how it works today, see Partial scanning.
Who is affected
- Impact: All Rencore Governance Customers
The change first ran as an opt-in preview and was then rolled out to all customers in all regions.
What changed
Since scanning is a core component of our product, the changes affect different areas, and there are required actions for you if you use our AutomationsAutomationAn automation is a workflow Rencore Governance runs on inventory objects when a trigger fires.Read more feature.
1. Improved scanning performance
What is changing: We optimized our scanning engine to process scans more efficiently, focusing on delivering value to your workspaces as fast as possible. We changed the scanning approach to save updated data to your inventory more often, instead of at the very end of a scan. Especially in large workspaces, we expect this to have a great impact on your experience. The changes take speed and data consistency into consideration, so some complex policies might only be updated at a later stage.
Previous behaviour: Scans updated the inventory only once during the finalization phase at the very end of the scan.
New behavior: Scans will run a finalization phase after every batchPartial scanningPartial scanning is the Rencore Governance scanning engine that updates the inventory while a scan is still running.Read more, i.e. 1,000 TeamsMicrosoft TeamsMicrosoft Teams is the Microsoft 365 app for chat, meetings and team collaboration.Read more, and update your InventoryInventoryThe inventory is the record of every object Rencore Governance scans from your tenant, with their properties and the relations between them.Read more accordingly, reducing the time it takes to see fresh data in your inventory.
Action Required: No actions required.
2. Frequent updates to Rencore artifacts
What is changing: Based on the updated inventories, we also update Rencore artifacts (SegmentsSegmentA segment is a saved, rule-based filter over inventory objects, for example every user whose country is the United States.Read more, Reports, Policies) more often if they are based only on a certain type of object. Artifacts spanning across relations will still only be updated once we have all the updated data, to keep data integrity.
Previous behaviour: Artifacts updated at the very end of a scan.
New behaviour: Artifacts that only contain objects at the very top of the hierarchy, i.e., User, Teams, Site CollectionsSite collectionA site collection is the top-level SharePoint container that holds a root site, its subsites, lists, libraries and files.Read more, etc., will be updated after every batch. We can update some additional objects more frequently and are trying to deliver the frequent updates to as many configurations as possible, without harming data integrity.
Example: A policy reporting a violation for every Team with a few owners was only updated once after the full Teams scan finished. Depending on the environment size, it could be hours or sometimes multiple days. With the new approach, we will update the policy after every batch, multiple times a day, independently of the environment size.
Action Required: No actions required.
3. Shortened time to action for automations
What is changing: Through updating the artifacts, like policies, more frequently, violations will also trigger attached automation runsAutomation batchAn automation batch is the group of automation runs that started from the same trigger at the same time.Read more once they are picked up. This will decrease the time you need to wait for your Automation to start running.
Previous behaviour: At the very end of a scan, we updated the Rencore artifacts, like for example policies, which triggered attached Automations. Even though this behaviour worked for small to medium-sized Automations, at a large scale, the time to run a scan, and the time to run sometimes hundreds of thousands of Automations needed improvement.
New behaviour: Policies eligible for batch updates are also triggering their attached Automations multiple times a day (we do not change the trigger logic, just the time when it triggers). Violations that have already been processed will not be re-triggered. The threshold of an Automation will now be handled as a daily threshold. The result will therefore be similar to the current logic of the threshold.
Action Required: Automations that run on policy violations now trigger more often during a scan than before, and their threshold applies per day. Check that your thresholds fit a daily limit.
4. Reduced impact of Graph API exceptions
What is changing: We closely monitor all your jobs. Even though the Graph APIMicrosoft GraphMicrosoft Graph is the Microsoft API that gives access to the data of the Microsoft 365 services.Read more is largely reliable, there are cases where the API is unresponsive or returns unexpected responses. In these cases, we have various fallback mechanisms or check them manually if needed, which can affect your experience through so-called “Job Pausings”. With our new approach, we pause only the batch that runs into issues and proceed with other batches to reduce the impact on your experience.
Previous behaviour: API exceptions may have caused paused scanning jobs to block updates to your inventory for a specific connector.
New behaviour: A paused batch will not affect other batches, and we will be able to reduce the impact on your experience. If data from a paused batch is required to update Rencore artifacts, it might still delay the updates of these.
Action Required: No actions required.
Benefits for your organization
The impact of the changes largely depends on the size of your Rencore and Microsoft 365Microsoft 365Microsoft 365 is the Microsoft cloud suite of Teams, SharePoint, OneDrive, Exchange and the Office apps.Read more implementation.
- Get actionable insights faster with progressive results delivery.
- Respond faster to compliance issues with more up-to-date data.
- Reduce the impact of Graph API exceptions.
What you need to do
If you use automations that run on policy violations, check that their thresholds fit a daily limit. No other action is required.
If you need help, contact [email protected].
Frequently asked questions
How often does Rencore Governance update my inventory during a scan?
Rencore Governance runs a finalization phase after every batch, for example 1,000 Teams, and updates the Inventory each time. Before, the Inventory was updated only once, at the very end of a scan.
Which Rencore artifacts are updated after every batch?
Artifacts that only contain objects at the top of the hierarchy, such as User, Teams, and Site Collections, are updated after every batch. Artifacts that span relations are updated only once all updated data is available, to keep data integrity.
Do I need to change my automations because of progressive scanning?
Yes, if they run on policy violations. These Automations now trigger more often during a scan, and their threshold applies per day, so check that your thresholds fit a daily limit. No other action is required.
Are violations that were already processed triggered again for an automation?
No. Policies that qualify for batch updates trigger their attached Automations multiple times a day, but violations that have already been processed are not re-triggered. The trigger logic itself did not change, only the time it triggers.
What happens when the Graph API causes a problem during a scan?
Only the batch that runs into the issue is paused, and other batches continue. Before, a paused scanning job could block Inventory updates for a connector. Updates to Rencore artifacts can still be delayed if they need data from the paused batch.
Was this page helpful?
Thanks for the feedback.
Thanks. What was wrong?