User Management

The User Management configuration is what controls help desk and OBO functionality.  You may in fact have more than one user management screen to provide a mutually exclusive experience for different types of authorized users.  The feature is broken up into three primary sections.

On Behalf Of User allowed to perform the following actions

This section is where administrators define exactly what OBO and/or help desk users are authorized to do as it relates to managing identities.  We will outline what each specific "Action" means in terms of functionality:

Profile Update Properties

This section is utilized for defining the approval rule to be used when updating profile information (i.e. attribute values for an Identity).  It is important to note that the Dynamic UI screen configuration is what controls whether or not an approval is required prior to updating corresponding Identity information.  If the Dynamic UI configuration is set to require an approval, the defined approval here for "Approval Rule for Update" will be initiated.  You can also make comments optional or required before an OBO / help desk user submits a request to modify profile attribute values.  Finally, a pre-process workfow can execute.  The goal of executing a pre-process upon submission on a profile update is to capture any external information that may be associated with a given attribute that was modified.  In the event of a modification to a key attribute value that correlates to access changes and/or vanity-type changes such as usernames, it is important to utilize this pre-process workflow to allow for abstraction and execution of follow on logic before the information is submitted for processing.  This workflow is often used to execute access qualification evaluations as a result of any relevant attribute changing that may affect access for a given user.

Manage Profiles on behalf of

This is the authorization filter that will authorize a set of OBO users to be able to perform the actions as defined above in the "On Behalf Of USer allowed to perform the following actions" section.  This filter is where we can discuss the need for multiple User Management configurations.  Currently, for each set of permissions an organization may want to enable for different levels of OBO / help desk users,  you will need to build out multiple User Management configurations.  The authorization filter defined within the context of the User Management configuration will only be applicable to the users that resolve to the filter (i.e. the members of a certain security group.  

As you can see, you are defining the user type, which is essentially the grouping of identities that the authorized requestors will be able to take action on behalf of.  In the example above, the user type is set to the "All Users" group. In this scenario it means that all users will be available to the defined requestor (which is the On-Behalf-Of Users" group to take the actions allowed by the configuration above.  Notice the "Profile Update Screen".  This is another configuration that may require administrators to build out a separate User Management configuration.  The reason is that Fischer offers dynamic control of what the actual profile management screen looks like for the qualified requestor type.  This means that you can build multiple views depending upon which requestor group you have defined.  

An example for this would be if you have multiple help desk levels defined (Help Desk 1, Help Desk 2 and Help Desk 3) and each level is authorized to see and take action on different attributes.  In this scenario, you would want to build out 3 distinct screens and build three distinct authorization filters and assign each screen to the authorized requestor group.  This provides governance to ensure that you can control what attributes a given layer of authorized user is allowed to see.  A good scenario here is you may not want a help desk level 1 user to be able to see and take action on profile attributes that are only reserved for executive level identities.  In this model, you have the ability to build out different screens and define which attributes each requestor type is allowed to interact with and modify as dictated by the permission settings above.

You will also notice the bottom configuration "User Profile Screen (Read Only).  What you need to understand here is that on the self-service User Management screen, upon searching for an identity you can display certain attributes of the person in a read only fashion.  Often times this information can be used to help the help desk user identify who the user is.  For example if you're ever asked, "tell me your name and full address" before we can proceed, and as the caller you will provide the information.  This configuration option provides administrators with the ability to control the attributes displayed as read only versus what attributes will be available further down the screen for actual modification.  This can help to limit the amount of data displayed as often times an identity's attribute list can grow quite significantly and can also be sourced from third parties.  This is a great feature for limiting what is displayed as read only so there is not so much noise on the screen or attributes that may not make sense to an OBO or help desk user.