• State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 96 subscribers
  • Views 3721 views
  • Users 0 members are here
Options
Related

unsubscribe workflow when Valid Until is reached

alberto bugoloni_20369
over 3 years ago

Hi all Community

I have a very peculiar question.

Is it possible to start an unsubscribe approval workflow when a product is removed from a person when Valid Until is reached? I know OI put the related PersonWantsOrg in Abort, but I’m still wondering if it’s possible to launch a workflow in the meantime, as could be the Cancellation Workflow.

 Currently I'm working on v.8.12. I read this Have resource Unsubscribe instead of abort when ValidUntil expires - Forum - Identity Manager Community - One Identity Community but maybe in the mean time something is changed...

Thank all of you in advance.

A

Parents
  • 0 over 3 years ago

    I don't think anything significant has changed regarding ValidUntil recently. I also don't think it should change:

    There is a decision/justification for the order to be ValidUntil. Afterwards there is no authorization for it to be present anymore. If there is need for it, a  new justification must be available in the system, so either a new/separate order afterwards, or a different decision before.

    We approach this normally by

    • disabling the "Soon to expire requests notification" schedule
    • instead start (sufficiently prior to the ValidUntil) a process to automatically Prolongate the PWO in question, possibly with a new ValidUntil date.
  • 0 over 3 years ago in reply to Klaus Müller

    Hi Klaus

    First off all, thank you so much for your reply. Everything seem very clear to me, but I still need to ask you something slightly different.

    We would like to intercept and prevent the “Abort”, independently by the reasons leading to those aborts, and start a cancellation workflow.

    Do you think this is possible? This means that we would like to treat the Valid Until not really as “the last day a product is assigned to a person” but as a “the day the cancellation workflow starts” and let the assignment on until the workflow is resolved, thus ignoring the Valid Until or the abort.

     

    Thanks again

    A

Reply
  • 0 over 3 years ago in reply to Klaus Müller

    Hi Klaus

    First off all, thank you so much for your reply. Everything seem very clear to me, but I still need to ask you something slightly different.

    We would like to intercept and prevent the “Abort”, independently by the reasons leading to those aborts, and start a cancellation workflow.

    Do you think this is possible? This means that we would like to treat the Valid Until not really as “the last day a product is assigned to a person” but as a “the day the cancellation workflow starts” and let the assignment on until the workflow is resolved, thus ignoring the Valid Until or the abort.

     

    Thanks again

    A

Children
  • 0 over 3 years ago in reply to alberto bugoloni_20369

    No it is likely not possible.

    Abort is generated by the system after the request (PWO) can not be active any more for (various) technically configured reasons. At that point in time it is too late to do anything about the current request.

    You can either act proactive in advance, which is what I suggested previously.

    Or you can create something new afterwards, for example in a follow up process or OnSaved-Script. (Much like the challange-role-membership functionality works). This will be much more complicated, may lead to endless loops and likely confuse your users. I strongly suggest to avoid this.

    Overall: Do not try to fix a faulty business process by technical means, FIX THE ROOT CAUSE by bringing the business process in line with reality. Afterwards you can implement it using technical tools like OIM.

  • 0 over 3 years ago in reply to Klaus Müller

    While I totally agree with Klaus in regards to the business process, there are use-cases where it is helpful if a time-limited request will not be aborted but goes into the unsubscription process. This is possible now with version 8.2.

    https://support.oneidentity.com/technical-documents/identity-manager/8.2/it-shop-administration-guide/40#TOPIC-1723513

    Canceling or unsubscribing requests

    DBQueue Processor checks whether the request's expiry date has passed using a scheduled One Identity Manager task, which compares it against current UTC time. If the expiry date has passed, the request is canceled; the resulting assignments removed. You can configure this behavior.

    If necessary, temporary requests can be unsubscribed. If the expiry date has passed, the unsubscription workflow stored at the decision guideline is run in this case. The unsubscription must be approved; only then will the assignment be permanently removed. If another request exists for the product, perhaps with the status Pending, the expired request will be canceled and replaced by the pending request.

    To unsubscribe temporary requests on expiry

    • In the Designer, set the QER | ITShop | ExceededValidUntilUnsubscribe configuration parameter.

    If the configuration parameter is set, requests with the status Assigned or Renewal will be unsubscribed. The unsubscription workflow entered in the approval policy runs through if no other request exists for the product, which now takes effect. Once the unsubscription is approved, the assignment will be removed. Expired requests with the status approved, pending, request are canceled.

    NOTE: If the unsubscription is denied, the approver must enter a new Valid until date. Otherwise, the request is given Assigned status and the unsubscription workflow runs again.

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    I stand corrected. It is 8.2 though.

    And I still think using this new feature might introduce some hassle in to your project. Better fix your business process.
    The referenced NOTE hints to the endless loop. More important in my opinion is: Make sure the Unsubscribe-Workflow has a timeout, else you'll end up with unlimited requests anyway. And that is a hidden (business process) danger that is very hard to catch/spot, while being audit/security relevant.

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    Marcus, Klaus, thank you

    This is a turn up for the books Blush

    I realize that leveraging this kind of option carry some risky consequences, but I’m quite sure we will handle them.

     

    Just let me please ask a couple of questions more.

    • What if, in case we set ExceededValidUntilUnsubscribe (in the next version, currently I'm working on 8.12), we do not configure a cancellation / unsubscription workflow?
    • From what you are telling me, it seems that this behavior is implemented only for assignment exceeding “Valid Until”. Is something similar implemented also for all kind of abort (for example a person that exits from a shop or if a product is removed from a shelf)?

     

    Again, thanks

    a