> For the complete documentation index, see [llms.txt](https://help.cymmetri.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.cymmetri.io/lifecycle-management/application-management/reconciliation-how-to/configuring-reconciliation-process.md).
# Configuring Reconciliation Process
Once the applications have been configured to allow that the end-users have been provisioned into the managed application. We may now start configuring the reconciliation process for an application. The reconciliation process involves identifying the user attributes as stored in the Identity hub (Cymmetri platform) and their attributes as a user or a group account in the managed application; and the ensuring that the synchronization of the user and group accounts takes place either one-way or both ways between the managed application and the Identity hub, to ensure that there no discrepancies in the accounts stored by both the systems.
\
The reconciliation process may follow two strategies -
1. **Full Reconciliation** \
Full reconciliation is typically carried out when the managed application is first introduced into an organization’s Cymmetri platform. This involves ensuring all user accounts (and group accounts, wherever applicable) from the Cymmetri platform, are synchronized with the account information on the managed application. This type of reconciliation often takes a longer time, and is often only used as a one-time activity.
2. **Filtered Reconciliation** \
The Cymmetri platform and the managed application might lose synchronization due to a number of reasons, including backend changes to the user or group account information on the managed application or failure of communication between the identity platform and the managed application. In such cases, filtered reconciliation is employed on a regular, scheduled basis. This includes filters for a particular set of users, or to choose only the users that have been modified on either platforms, this is known as filtered reconciliation.
Cymmetri platform allows for both types of reconciliation phases, by allowing administrator to define an optional user filter during the reconciliation process.
The reconciliation process involves two major processes:
1. **Pull**\
In this mechanism, the Cymmetri platform allows for user and group account information to be pulled from the managed application.
2. **Push**\
In this mechanism, the Cymmetri platform pushes the user and group account information to be pushed to the managed application.
Regardless of the process employed, the configuration for the most part remains the same.\
Let us explore the reconciliation configurations on the Cymmetri Platform:
You may access the reconciliation menu by clicking on the application tile, and then clicking on the “Reconciliation” left-hand side menu.
Proceed to configure by clicking on the “+ Add New” button.
1. **Name:** Refers to the name of the Reconciliation process
2. **Modes:** FILTERED\_RECONCILIATION (Currently the only mode supported by Cymmetri)
3. **Sync Fields:** The field from the user/group’s account information as available on the Cymmetri platform that must be used as a basis to identify the corresponding account on the managed application database.
4. **Source Attributes:** The field from the user/group’s account information as available on the managed application database that must be used as a basis to match with the “Sync fields”.
5. **Status:** Whether to run the reconciliation for Active/Inactive users.
6. **Type:** Some applications allow GROUP reconciliation, but most will have USER reconciliation only.
Filled Reconciliation basic configuration looks as above.
### Synchronizing Scenarios and Their Corresponding Outcomes
Let us assume we are synchronizing the Cymmetri Platform with a cloud provider using email or mail attribute as the Sync field. As such users on both platforms having the same email address will be matched/un-matched.
#### Following are the scenarios managed by the Cymmetri platform -
1. **User does not exist in Target system & exists in Cymmetri:** \
This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform, but not in the managed application. This typically occurs when the users have been pulled into the Cymmetri platform, but the managed application is yet to be synchronized with these users.
2. **User exists in Cymmetri & Target system:** \
This indicates a situation during a pull phase or a push phase, where the user account exists on the Cymmetri platform and in the managed application, but they may or may not have the same attributes or the same values of the attributes.
3. **User exists in Target system & does not exist in Cymmetri:** \
This indicates a situation during a pull phase or a push phase, where the user account exists in the managed application database but not on the Cymmetri Identity platform. This typically occurs when the users have been pulled into the managed application through its backend and the users have not been centrally managed through the Cymmetri platform.
### Conditions Explained:
1. **User does not exist in Target system & exists in Cymmetri:**
1. **PROVISION:** User is created in the target system with the attributes as present in their Cymmetri user profile.
2. **IGNORE:** User is not modified in either system.
3. **UPDATE:** Not relevant for this scenario.
4. **DEPROVISION:** User is removed from the Cymmetri platform to be consistent with the managed application user database.
5. **UNASSIGN:** Not relevant for this scenario.
6. **ASSIGN:** User is assigned access to this system in Cymmetri, this option may be used in the case of options like JIT being available to generate user profile in the managed application.
7. **UNLINK:** Not relevant for this scenario.
8. **LINK:** Not relevant for this scenario.
2. **User exists in Cymmetri & Target system:**
1. **PROVISION:** User is created in the target system with the attributes as present in their Cymmetri user profile.
2. **IGNORE:** User is not modified in either system.
3. **UPDATE:** User information from the Cymmetri Identity platform is updated using the account information from the managed application and vice versa.
4. **DEPROVISION:** Not relevant for this scenario.
5. **UNASSIGN:** Not relevant for this scenario.
6. **ASSIGN:** User is assigned the managed application on the Cymmetri platform in case they are already not assigned.
7. **UNLINK:** Not relevant for this scenario.
8. **LINK:** Not relevant for this scenario.
3. **User exists in Target system & does not exist in Cymmetri:**
1. **PROVISION:** User is created in the Cymmetri Identity platform deployment using the account information from the managed application.
2. **IGNORE:** User is not modified in either system.
3. **UPDATE:** Not relevant for this scenario.
4. **DEPROVISION:** User is removed from the managed application user database.
5. **UNASSIGN:** Not relevant for this scenario.
6. **ASSIGN:** Not relevant for this scenario.
7. **UNLINK:** Not relevant for this scenario.
8. **LINK:** Not relevant for this scenario.
Scheduling the reconciliation process:
1. **Next Execution Date:** \
This indicates the base date to start the execution date and time of the reconciliation process.
2. **Cron Expression:**\
This indicates the frequency with which the further reconciliation events will be run. There are 6 fields here - \* \* \* \* \* \* (e.g., 5 15 0 1 8 \*) ; they refer to seconds, minutes, hours, days, months, and year after the first execution date.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.cymmetri.io/lifecycle-management/application-management/reconciliation-how-to/configuring-reconciliation-process.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
