none
Achieving auto-selection of department heads when user fills up the department they belong to-FIM 2010 R2 RRS feed

  • Question

  • Hello,

    How can one configure auto selection of department heads every time a user fills up the department they belong to?

    Just a little detail on my issue, I have a custom access rights request form. Every time a user fills up their department, the form is supposed to auto-fill the head(s) of the department who's thereafter required to approve or reject the user's access right request. How can I achieve this?

    Any ideas on how to hack this?

    Sunday, October 26, 2014 5:34 AM

Answers

  • Hello,

    I dont know your exact solution and how you implemented that custom form, but here are some approaches.

    You should have departments as objects in portal, each with a manager reference attribute set.
    You can also create a custom attribute on users for that department, also as a reference attribute.

    So if users have departmentReference set you can access them like that:

    [//requestor/deparmentRef/managerRef]

    for example also in approvals.

    All other solutions I think, if you dont have departments as objects, needs to be special coded with having a list of all department and their managers.

    Keep in mind that with the default portal UI you can not select a second attributes value when another attribute value changes.

    But you can do that in custom UI forms which are not supported but will work fine.

    Eihab Isaac has written a lot of posts about that on his blog, and also did a great presentation on the FIM User Group.

    Regards
    Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com


    • Edited by Peter_Stapf Sunday, October 26, 2014 8:59 AM Hint for Eihabs blog
    • Marked as answer by Josephine254 Monday, November 10, 2014 7:38 AM
    Sunday, October 26, 2014 8:07 AM

All replies

  • Hello,

    I dont know your exact solution and how you implemented that custom form, but here are some approaches.

    You should have departments as objects in portal, each with a manager reference attribute set.
    You can also create a custom attribute on users for that department, also as a reference attribute.

    So if users have departmentReference set you can access them like that:

    [//requestor/deparmentRef/managerRef]

    for example also in approvals.

    All other solutions I think, if you dont have departments as objects, needs to be special coded with having a list of all department and their managers.

    Keep in mind that with the default portal UI you can not select a second attributes value when another attribute value changes.

    But you can do that in custom UI forms which are not supported but will work fine.

    Eihab Isaac has written a lot of posts about that on his blog, and also did a great presentation on the FIM User Group.

    Regards
    Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com


    • Edited by Peter_Stapf Sunday, October 26, 2014 8:59 AM Hint for Eihabs blog
    • Marked as answer by Josephine254 Monday, November 10, 2014 7:38 AM
    Sunday, October 26, 2014 8:07 AM
  • You need to auto select this in a form or you want to execute it in approval? If you are using standard FIM UI you can't do this and also when you will submit the request in standard way you will be able to do this in action workflow. If you want to have this request approved by specific person before doing any other action you can calucate approver on the fly based on request detail - in your case lookup department head - and use it in approval activity. 

    I've done this multiple times however this requires a bit of custom code which will calculate approver for you in authorization phase workflow. 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Sunday, October 26, 2014 6:21 PM
  • Thanks Peter.

    Interesting the way you have put it is. I had not thought that double references could work in a parameter as you have suggested with [//requestor/deparmentRef/managerRef]. Let me try that out with department head as a reference attribute as I do have with the managers and supervisors to see how it goes.

    I will update on my findings. Much appreciated.

    Sunday, October 26, 2014 8:33 PM
  • Thank you Tamasz.

    You caught my attention when you mentioned "If you want to have this request approved by specific person before doing any other action you can calucate approver on the fly based on request detail - in your case lookup department head - and use it in approval activity" please elaborate. Also, if you don't mind, could you share a piece of custom code that helped you achieve the above... or make recommendations of blogs one can read to get informed on the same please?

    I appreciate your assistance.

    Regards.

    Sunday, October 26, 2014 8:39 PM
  • I have tried out your suggestions. Still trying to hack a custom code (powershell activity) to use. I have never used Powershell activities on FIM before... 

    I created a department head reference attribute and every time I try to use it on my approval workflow it fails. I get the famous Denied status. This is how I use it in the parameter, [//Target/DepartmentHead]. Interestingly enough, [//Target/Manager] works just fine but the department head one. Could you be having a as to what I could be doing wrong?

    Both the manager and the departmenthead attributes are reference attributes.

    Tuesday, October 28, 2014 1:29 PM
  • Hi,

    have you modified the Default MPRs or create a new MPR to give permission to this new Attribute ?

    Regards
    Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, October 28, 2014 2:39 PM
  • Hi Peter,

    I have not modified or created any MPR. Is that a requirement for reference attributes? 

    Kind regards.

    Tuesday, October 28, 2014 7:19 PM
  • Hi,

    its a requirement for all custom attributes to set permission on it to read or modify it.

    Only exception is the built-in  Forefront Identity Manager Service Account (the Portal/Service) itself.

    So create a permission MPR to give the appropiate accounts read and modify permissions to the new attribute.

    And just a hint, my suggestion was to having the departments as objects in FIM each one with a department head attribute. then make a reference to the user object. Depends on if you have an source to get departments as objects to FIM.

    Bit your way should also be work.

    Regards
    Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, October 28, 2014 7:50 PM
  • I get your point now Peter, the department as object bit. Must have not understood it at first.

    Just to clarify the creation of FIM object as I have not tried it before, is this where I have to create a workflow activity using Visual Studio or PowerShell Activity?

    BR


    Wednesday, October 29, 2014 6:28 AM
  • Hi,

    you do not need any code or powershell nor a custom activity to archive the goal, with my suggestion.

    I would preferr to import those department objects from a source (ex. HR).
    Create or let create a table or view (if HR is SQL based) with department objects with at least two attributes (name and head).

    Import those data to MV (head as a reference), and export it to department objects in Portal/Service.
    Modify User table from HR so that it has also a reference to the department objects.

    You should then be able to use the departments head in your approvals, there is no need for users to choose their department anymore in a custom form.

    Hope that fits your needs and is possible at your side.

    Regards
    Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Wednesday, October 29, 2014 9:09 AM
  • Yes Peter, this is possible. Thank you a lot. Much appreciated.
    Wednesday, October 29, 2014 1:23 PM