none
How have others solved this? FIM portal custom object - request access to a system for end user RRS feed

  • Question

  • All,

    I am just starting my research and wanted to see how others have solved this problem before I go too far down this road.  I have a requirement to create a custom object in the FIM portal that allows a user to request access to other systems.  

    1. The preference is to have a separate custom object (MySystemRequests) instead of modifying the primary user object in the portal.  Easy enough.
    2. The new custom object "MySystemRequests" will contain several fields including a multi-value check box called "Request System Access" to request access to systems like payroll, accounts receivables, etc...  Again pretty straight forward.
    3. Here's where it might get tricky.  An a separate approval for each system selected on the "Request System Access" should be created when the MySystemRequests is submitted.  Each selected item may have its own approval workflow and automation that it needs to follow - hence the need for separate approvals.

    My question is, short of writing a custom activity is there a way to spawn multiple approvers for a multi-value checkbox?  Any thoughts and insights would be appreciated.

    Monday, February 1, 2016 8:15 PM

All replies

  • Hi I would appreciate any comments from those who have crossed this bridge before!  

    Cheers!

    Wednesday, February 10, 2016 5:36 PM
  • Hello,

    If you're trying to setup different approval workflows for each system, I'm assuming that each system is associated to a different attribute on the MySystemRequests object.

    Given that, you should be able to define a Request MPR targeting a single "system" attribute, with its own approval workflow (and list of approvers).  When the MySystemRequests is created, the MPR(s) should all start their own approval workflow(s) for each "system" that is checked.

    One thing to keep in mind; if a MySystemRequests object contains multiple systems that must be approved separately, then an approver denying/rejecting their specific "system" will cause the whole request to fail, including any "approved" systems.

    Cheers,

    Marc


    Marc Mac Donell, VP Identity and Access Solutions, Avaleris Inc.
    http://www.avaleris.com

    Wednesday, February 10, 2016 6:48 PM
  • Thanks for the response Marc.  In this instance the current is requirements is to have a multi-valued field where the users could select access to multiple systems such as AD, SalesForce, Google Apps etc.  From there we would want to spawn an approval request for each individual system requested.  

    So if the user creates an Application Request and selects 4 systems in that multi-value field the idea is to have 4 separate approvals sent to the person's manager.  We would like to do this without going down the custom activity route.  

    Thoughts?

    Wednesday, February 10, 2016 7:07 PM
  • Unfortunately, the request MPR that you would use for setting up the approval workflow(s) is only looking at the submitted request, so changing a multi-valued field/attribute is treated as a single request.

    One approach you could use is to take advantage of the Target Resource Definition After Request when defining the request MPR(s) for the approvals.  If you create a set of all MySystemRequests with that have system X in the multi-valued field, you can target a specific approval workflow against those requests that would eventually add the object to that set.

    You would then need to create n groupings of MPRs/Sets/WFs for each possible system, if you wanted to different approvers for each system.

    You still need to keep in mind that even with this approach, you are potentially spawning multiple approval requests (if more than 1 system selected) against the original request.  The FIM request processing pipeline will complete that original request only if all approval requests are approved, and only when all them have been approved.  If any are denied, the whole request will be rejected (including any approved systems), given that you're really only dealing with 1 request to change a multi-valued field.

    Cheers,

    Marc 


    Marc Mac Donell, VP Identity and Access Solutions, Avaleris Inc.
    http://www.avaleris.com

    Thursday, February 11, 2016 12:48 PM