Share all details about your problem, including any error messages you may have received.
I am working on a requirement where data flows from **HR Source ** to SailPoint consumes as an authoritative source. Alongside this, we have an additional module called Contract Record that stores the following attributes:
Start Date
End Date
Suspend Date
Suspended (Yes/No)
Access information related to specific roles
Each Contract record is associated with an identity, and a user can have multiple Contract records.
Key Use Case:
When a new Contract record is created for a user (e.g., new user created or due to a role change):
Access associated with the new Contract Record should be provisioned based on the new start date.
Access associated with the old Contract Record should remain active until its end date.
A manager can extend an existing Contract Record’s end date. In such cases:
The system should delete any newly created “Contract Record” records associated with the same identity.
The access associated with the extended Contract Record should continue without disruption.
Handling suspended users:
If the suspend date is set, all associated access should be disabled without deleting the **Contract Record **.
Overlapping Contract Record :
Ensure there is no conflict when multiple Contract records overlap for the same identity.
What is the best design approach to synchronize and reconcile Contract Record data with identity attributes in SailPoint, given the following requirements:
The need to handle multiple use cases like provisioning access based on new and old Contract records, extending existing Contract records, handling suspended users, and managing overlapping Contract records.
I recommend creating an intermediary data source, such as a database, to store records mapping users to contracts. Each contract can be linked to an identity cube as an account through aggregation from the database using a JDBC connector. Based on the data aggregated into the system, you can take necessary actions accordingly, such as enforcing start and end dates for the contracts.
To implement this, add a relationship attribute in the database that ties the user to the contract. You would also need to figure out how to provision data into the intermediary source, which I will think about further.
This is not a full solution, but it’s probably a good starting point. You can explore ways to simplify further. For instance, instead of a traditional database, you could consider a NoSQL solution like AWS DynamoDB. Using a web services connector, this approach could reduce costs compared to relational databases. Hope that helps as a starting point!
You could aggregate each Contract Record as a separate link.
A trigger (lifecycle event) would for added/removed/changed Contract Record links and launch a workflow.
The workflow would check which Contact Records are active (after start, before end, not suspended) to determine the access that should be provisioned.
The workflow would then compare that with the access that is actually provisioned, and make any needed changes.
The workflow would also determine the next upcoming start/end date and schedule a request to run the workflow again at that time.