Example: Using Marks to Quarantine Failing Resource Objects

Last modified 23 Feb 2026 08:22 +01:00
Table of Contents

This shows an example of utilizing marks to fix issues encountered when running tasks.

Failure scenario

In this example, we are using marks in a reconciliation scenario so that we can automatically quarantine resource objects (shadows) that fail during reconciliation due to invalid or corrupted data in the source system.

The presented scenario is used in situations that have the following typical symptoms:

  • Reconciliation repeatedly fails on a subset of resource objects due to invalid or corrupted data.

  • The data issue must be fixed in the source system before the objects can be successfully reconciled but you need a temporary workaround to keep the reconciliation process running for the rest of the objects.

  • The failing objects are not critical and can be safely quarantined until the source data is fixed.

  • You want to avoid repeatedly processing the failing objects during reconciliation as continuous retries provide no value and only cause unnecessary load on the system.

Mark-based quarantine

The example solution below runs a reconciliation, immediately identifies failed objects, and applies a mark to them, so that a shadow policy can automatically quarantine them until you can identify the root issue, fix the source data, and remove the mark.

The solution employs failed objects selector and shadow policy marks.

  1. Create a composite task containing two activities chained using the <composition> element in the task definition:

    • The first activity runs a reconciliation on the resource.

      Example of the first activity:
      <activity>
    <order>1</order>
    <work>
        <reconciliation>
            <resourceObjects>
                <resourceRef oid="b13181b7-627c-495a-af4a-148cb657effd" relation="org:default" type="c:ResourceType"/>
                <kind>account</kind>
                <intent>default</intent>
            </resourceObjects>
        </reconciliation>
    </work>
</activity>

    • The second activity immediately processes only the failed objects (using failedObjectsSelector) and applies a mark to them. This mark makes sure that the system automatically quarantines the marked shadows, and that you can find the failed objects to review and fix the source data issues.

      In this example, we are using the Invalid data mark (with OID 00000000-0000-0000-0000-000000000804) that is provided in midPoint by default for such purposes. The benefit of using a predefined mark is that the system will automatically quarantine the marked objects.

      If you use other than a system provided mark, you will need to define a shadow policy that will quarantine the marked objects.
      Example of the second activity:
      <activity>
    <order>2</order>
    <work>
        <iterativeScripting>
            <objects>
                <type>c:ShadowType</type>
                <!-- This is the key: select objects that FAILED in the reconciliation activity run -->
                <failedObjectsSelector>
                    <selectionMethod>fetchFailedObjects</selectionMethod>
                    <status>fatal_error</status>
                    <taskRef oid="f327ec63-28bf-4765-9aac-48e0c17ae09c" type="c:TaskType"/>
                </failedObjectsSelector>
            </objects>
            <scriptExecutionRequest>
                <s:action>
                    <s:type>modify</s:type>
                    <s:parameter>
                        <s:name>delta</s:name>
                        <c:value xsi:type="t:ObjectDeltaType">
                            <t:changeType>modify</t:changeType>
                            <t:objectType>c:ShadowType</t:objectType>
                            <!-- Add policyStatement = apply Invalid-data mark -->
                            <t:itemDelta>
                                <t:modificationType>add</t:modificationType>
                                <t:path>c:policyStatement</t:path>
                                <t:value>
                                    <c:markRef oid="00000000-0000-0000-0000-000000000804" relation="org:default" type="c:MarkType"/>
                                    <c:type>apply</c:type>
                                </t:value>
                            </t:itemDelta>
                        </c:value>
                    </s:parameter>
                </s:action>
            </scriptExecutionRequest>
        </iterativeScripting>
    </work>
</activity>

    See the full composite task example.

  2. Once the mark is applied, the marked shadows are automatically quarantined, and subsequent reconciliation runs can skip the marked shadows (until unmarked) instead of repeatedly processing them. Applying the system pre-defined Invalid data mark causes the default shadow policy to quarantine the affected shadows by disabling synchronization (inbound/outbound) and provisioning operations until the mark is removed.

  3. Review the marked shadows to find out what data are incorrect. You can do this in  Dashboards (see Introduction to dashboards in midPoint).

    Alternatively, depending on your context, you can also see  Resources >  All Resources > your resource >  Accounts (or  Entitlements) or other sections in the GUI.

    Set up notifications to automatically notify the responsible administrator about the failed objects.

  4. Fix the source data in the connected system.

  5. Remove the mark from the shadows (in  Resources >  All Resources > your resource >  Accounts or other section, depending on your context), and then reconcile the objects manually, or wait for the next scheduled reconciliation run to process them.

Was this page helpful?
YES NO
Thanks for your feedback