I realize this is a documentation discussion area, but are product owners satisfied with 24 hour cycle for data visibility?
As search is the core of campaigns, SoD, and reporting, isn’t 24 hours very excessive?
1 Like
Thanks for sharing this question on our documentation. I’ve moved it to the Ideas and Discussions category to get more help from the broader community.
@Colin might be able to help with this question.
1 Like
On the surface I am quick to react: 24 hours is not great. But 24 hours for what level of data needs more diving into. Is it all indexes all attributes etc.
For example, 45 accounts across 45 systems (sources). All entitlements across those systems? Cloud brings another level - all the permissions and all the millions of resources? And we have to consider saas/iaas systems api throttling etc. and implementations like exponential retry etc. Then you wonder would less than 24 hour collection be even feasible for some scenarios.
After that the collected data would have to be added/reindexed.
Would customers pay more for more frequent collection, processing, and indexing. How could we slice up some high value areas and make it a fair value prop for everyone.
Lets discuss further… is there something ‘less than everything’ that we could start with. Is it account?
As far as I can tell, this question is about data that was already aggregated into Identity Security Cloud and simply doesn’t get indexed for up to 24 hours.
1 Like
I would say that the 24 hour timeframe IS excessive since the data is already in the system (which is what I have encountered.)
We ran into this this week actually when trying to set up a last minute Certification PoC for an internal team, and the entitlements would not show in the Entitlement Catalog, or the Certifications. We ended up Cancelling the PoC meeting because we were unable to show anything.
Additional scenarios which I have encountered in the past that are affected:
- Entitlement aggregation is either off, or set to weekly, but the Source had an entitlement added after the last aggregation that is necessary for a certification that is starting today.
- PoC work where new data may need to be pulled in based on discussions. Many times I have been working with stakeholders who ask if we could pull in data and I’ve done it on the fly and it helps get buy in/approvals from them.
- Deploying/migrating objects to new tenants. If the certification can not be configured until 24 hours after the source is configured and aggregated, that will prolong deployments. Especially in cases where there are strict change windows for configuring code/UI changes.
2 Likes
Paywalls for using expected functionality may not yield desired results.
In our case, we use manually built CSV sources for campaigns which involve sources not yet connected.
A single flat file of Entitlements is aggregated first, then accounts.
Typically, these have shown up in search nearly instantly, but recently, there seems to be some sort of growing processing delay. Our account CSM referenced the documentation saying that 24 hours is how long search requires for update.
Perhaps, in this case, it would be appropriate to offer an API and UI update per source similar to the “Apply Changes” button for Access Profiles. Maybe for consistency, it’s just an “Apply Changes” button that triggers indexing for the accounts and entitlements in the source, ensuring that the affected identities are up to date.
@rmccoy-unum We have also noticed this change recently with long delays. And we will likely be running into the same situation as you are with the Flat Files, as we are working to define some disconnected sources currently.
I agree that an “Apply Changes” type button would be helpful in many cases where the administrator is working to set up the system, or load offline data, but an Administrator is not always going to be around to hit it when a new entitlement comes in from a connected source.
@Colin Does this mean that the new SLAs for data being correct for entitlements is now 24 hours after they have been aggregated? And that an Administrator should not consider entitlements available and actionable until then?
This information will be important for certifications, especially those that are scheduled, as they would need to make sure that no new entitlements have been added to the system within 24 hours of the preview getting generated, otherwise those entitlements will not be included in the Certification itself.
NOTE: I am talking strictly for Entitlement that are net new to the system. I don’t know how this will affect existing entitlements that are aggregated for a user, though that should be evaluated as well.
2 Likes
The desired result is everyone is happy. Trying to understand the feature.
Expected functionality is:
(1) CSV source data is uploaded into the system
-
Account name
-
Entitlement name
(2) Uploaded source data is retrievable via search query less than NEW TIME (one hour?? less than 2 hour??)
The CURRENT TIME of <24 hours is too large of a window. Basically don’t want to revisit something you started yesterday is how I think about this. I’d forget.
An API call to decrease said data appearing < NEW TIME is acceptable. (eg solution does not require automation via the upload or a UI)
I am not aware of any changes to the system or SLA. But others are observing a longer delay too. It seems like previous experience for reflection of the csv data in search was reasonable - and may not require some new feature.
tell me if I am way out in my understanding please!
Functionality summary is as expected. We are accustomed to immediate availability because that’s what it was until recently.
What’s very strange is that this used to be (a few months ago) instantaneous. Immediately after uploading entitlements and accounts, they were searchable. In our previous quarterly campaign, we noticed that there was a lag - most entitlement items showed up immediately, but some were not visible until the next day. When we tried the same procedure we usually follow this week, none of the entitlements were visible after loading several CSV sources.
@Colin I share the same experience that Robert had, where they used to be instantaneously available, and now there is a delay.
As Robert pointed out, this becomes an issue as we get into our Q3 Certifications, because now we can’t confidently state that:
“The entitlements included in the Certification are the entitlements that existed in the Source system when the certification was generated”.
The statement is now:
“The entitlements included in the certification are the entitlements that existed in the Source system the day before the certification was generated.”
There is a big difference in those statements especially for auditors.
2 Likes
Hi Geoff,
Did you get any workaround for this issues? We are noticing something very similar to your issue. The entitlements are not showing up in entitlement catalog and search.
Is there are workaround to show them earlier?
Regards
Arjun
1 Like
The current workaround is to wait up to 24 hours. No way around it at this time unfortunately.
I believe we are still waiting for @Colin to confirm that this is now the new expected process, and the previous experience, where they were visible immediately after aggregation, is no longer available.
In the mean time, I have created an Idea for this to be updated: https://ideas.sailpoint.com/ideas/GOV-I-3932
1 Like
No workaround or even explanation of why such a change was made was provided. It’s definitely a downgrade in real-time certifiability.
We are facing the same issue with Active Directory and the time frame has already crossed 24 hours and yet we don’t see the entitlements in ISC under the Entitlement Catalogue.
Welcome @ssonkamb !
Please open a support issue as this exceeds 24 hours.
Thanks @gmilunich , I will let @sara_khan (Cert) and @jordan_mandernach (Search) know.
2 Likes
Just looking for an update on this as a lot of the tiles in Workflows are some variation of the Search API, and we cannot confidently build any automation when we are being told that a random 24 hour delay in data is “expected behavior”.
There’s documentation of SailPoint fixing an audit event issue that was delaying search ingestion and creating a bad experience for customers. Even has metrics stating they reduced avg search latency from 59 minutes to 1.5 seconds, so obviously this is not expected behavior and was fixed in the past. Here is the post :
Can we just get a level of transparency and communication somewhat similar to this blog post please? Because editing documentation to throw in a sentence that states any random delay in data under 24 hours is “expected” behavior, then having support just repeat it to us when we submit tickets, is not going to sit well with anyone who has used this platform regularly within the last 3+ years and knows that is not true.
2 Likes
I am running into this again. It seems that the time for the entitlements to show in the Entitlement Catelog has improved some, as I was able to see my entitlements within an hour (I did not check sooner, so unsure of the exact timing. It was not correct within 5 minutes of the Entitlement Reset then Re-Aggregation )
However, I am now running into the Entitlements do now have the Identities updated on them, while the Entitlements do show on the users. There are only 73 entitlements and 115 users, so it should not take long to process them.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.