manual approve single blocked entitlement
R
René de Jong
I agree with Patrick HORYN, but understand the danger Rick van den Dijssel is pointing out. May be it is an idea to add a warning before the approving action that approving this one could lead going below the threshold and can unblock the rest after a new enforcement. So if you don't want that you can increase the threshold, first before approve the single blocked entitlement
R
Rick Nieuweveen
In this use case, I would like to approve a single blocked action. As Patrick also mentioned, I want to be sure that the action has the right effect; It is not allways clear what the impact will be. The next step would be to approve the other 9 actions.
It is not the intention to pass 1 action and leave the remaining 9 in place.
I think if things need to be sorted out for a specific action for a user it should be temporarily excluded.
R
Rick van den Dijssel
Rick Nieuweveen: If I understand you correctly it's not about the number of actions or if they are started for the correct reasons but more about if the action works as intended and correctly. So in short you want to have more forecasting/testing capabilities to try an action in different scenarios? Or have more control which action to start so you can test the action before running it in bulk
R
Rick van den Dijssel
The issue with approving a single blocked entitlementis that it could end up with sort of approving all blocked entitlements for that particular system and type. As example if my threshold value is 10 revoke actions for a system. The threshold is triggered because 10 revoke actions want to be executed. Now I approve a single blocked entitlement (which we have 9 revoke actions left). Now the next run comes in to play this time I only have 9 revoke action so the Threshold isn't triggered. Therefore all 9 revoke actions will be executed.
Please keep in mind that the blocked actions are cleared every reforcement and with this we reaveluate if the threshold are met on that enforcement. Why are we doing this? This is because if you have a HR mistake which set's all the contract end dates to yesterday we would block this in the scheduled enforcement. But if HR fixed the data it will be correct in the next enforcement run without any inteference from a Administrator. Which makes it easy to fix this if they are data related issues.
This all actually means that the thresholds are a system with should only block things if something is wrong it's a last defence against major issues. Therefore it should not be used in your regular offboarding/onboarding process.
My question to you guys is how are you using the threshold in the use cases above? To me it seems like you're using the threshold as a system of control instead of a last defence system. Why are you doing this and what is the need you're trying to solve?
Twan Duvigneau
Rick van den Dijssel: Adding a button the the blocked actions to delete the triggered actions would "fix" your fist example. It would also fix other feature requests like triggering an update for everybody when adding a custom field. If you have a threshold on the update action then we could just delete the triggered actions and we would not be executing for example 70.000 actions. I agree with your opinion that the feature should not be used as a system of control, but I do think that adding a delete actions button would fit the current use case of the blocked actions.
R
Rick van den Dijssel
Twan Duvigneau: Unfortunately your solution of a button to remove actions will not work because on the next enforcement, it will start a new revoke action which again could be blocked by the treshold depending on the number of actions (in my example it will start a revoke for the 9 actions left which is below the threshold). This is because our engine always wants to accomplish the desired state as configured in business rules.
The above reason is why I would like to know more about the issue. Then I can discuss this with development or other parties to come up with the best solution to solve the issue.
Twan Duvigneau
Rick van den Dijssel: I see what you mean, it's not completely what I meant. After deleting the actions in the blocked actions it should not really throw away the actions, because that would trigger new ones indeed. But it should skip the actions and see it as completed. Then it would not trigger again. So maybe "skip" would be better than a "delete" button, or unmanage.
M
Matt Bianchi
Rick van den Dijssel: Making a minor change to a person object such as adding a new field will trigger updates in every single target system for those users. This can cause 1000s of updates to appear that won't actually do anything but the clients (and techs oftentimes as well) get worried about this and would like to see a handful of users go through the process as reassurance that the process will not run over and possibly update 1000s of users in a way they do not want.
Ideally we'd have some way to control what attribute updates effect which parts of a system or the system as a whole. For example in the Active Directory system we don't need to worry about changes to a field called personalEmail we would simply be able to uncheck that field from Active Directory > Update (or even just the Active Directory target system itself) so any changes for the field personalEmail simply will be ignored by the Active Directory target system. This would have the added benefit of not causing 1000s of updates to appear and try and process for systems in which the application is going to do nothing and would save a massive amount of processing time/power. (This is also discussed here: https://helloid.canny.io/provisioning/p/skip-updates-when-adding-custom-fields) Though I imagine that would require significant development effort so this solution acts as an easy common ground.
P
Patrick HORYN
After few month of production, a customer can ask for a modification in the Post Action script of a target system. So we need to be sure the revoke action works correctly before revoking massively all users. That would be the idea of unblock action option for only a sigle person to make preview/test of the new action script.