Assuming we had an authoritative source built behind a Flat File, Custom Web Services, or JDBC based Connector, would it be possible to configure the source to be based on a data set that showed deltas (changes) only? One of our partners has suggested providing a feed to us for an authoritative source that would have a one time initial load for all users, but following the initial load they would only want to show deltas. From everything I’ve seen so far, SailPoint does not support basing an authoritative source on a data set that shows Delta’s only; however, I am not 100% sure of this.
This should be possible if you disable the “account deletion” option on the aggregation page. I’ve not come across a use case like this yet, but theoretically, should be do-able given my previous statement.
Right, but then a true deletion would not be able to be processed correct? Instead a user would just be left in the last state it was in prior to the deletion. I would think SailPoint would want to disable any and all downstream resources that a user may have in the case of a delete. Is this possible if delete is turned off for the source, and a authoritative source is sending only deltas?
That’s correct. Ideally, the authoritative source shouldn’t delete records, but rather show some attribute indicating they are disabled. This would still kick off the downstream processes assuming you had the lifecycle states setup correctly.
In your case with the deltas, this would only work assuming the delta would tell you when the user gets terminated. For example, if the status field changed from active → inactive. If the authoritative source can’t notify that the user is being terminated through some attribute change other than the record being deleted, then this will not work for you.
How should we handle a case in which our authoritative source does delete records? I have recently been informed that our Workday source can sometimes delete records. Is there a way to trigger disables downstream using a lifecycle state in cases where an authoritative record is deleted and we have delete turned on for the source?
I would use the trigger below to handle deleted accounts from an auth source. This can handle cleanup for downstream sources so you aren’t left with orphaned uncorrelated accounts.
This still does not work assuming you are only sent deltas. How would you be notified that a record was deleted if you are only sent a delta?
Hey Tyler,
My last question was assuming a full data load, not a delta, with delete turned on for the Source.
So it sounds like a delta load is fine for any source (i.e. JDBC, WebService, or Flat File) as long as Delete is turned off. This assumes we don’t need to actually support a case where a user record is actually deleted. The business partner we are working with wants to send delta’s once a day because they do not want to store the data, and the data is a little bit sensitive. What I do not like about a daily delta feed with this setup is that we only have one chance (assuming we sync once a day) to sync that data in, and if anything is missed (which seems inevitable) we will not have a way to sure up the data. I am considering asking the business partner to keep delta’s for up to a week maybe, or requesting that we are able to see a full set of data somehow weekly maybe - to ensure if anything is missed we can sure up the data.
Also, one other question.
The Webservices and JDBC connectors have a “Delta” Aggregation option - Flat File does not.
However, I am thinking the “Delta” options on the Webservices and JDBC connectors assume you are getting a full population from the source, and it allows you to pick some kind of attribute from the source to distinguish recent changes/deltas. Am I right about that assumption?
Ah I see, that’s correct. Any source should be able to handle it assuming delete is turned off.
I agree that only having the delta’s for one day could potentially be troublesome if the aggregation fails one day for any one of these reasons: password, network, ISC stability . I think either a weekly full push or at least leaving the deltas in for a week at a time would work. I prefer a weekly full push since we could also capture deletes there.
That’s correct.
The delta functionality there is not like what you are describing in your original post. It relies on an attribute and can still handle record deletions unlike your version.
Thanks for the feedback Tyler! I think we have what we need now