Skip to main content

Edit Application Attribute

Application Details & Attribute Editing Steps​

The first step of editing the application details and attributes is go to the Manage Catalog section of IDHub. Click on the Manage Catalog link in the left menu (Or you can also click on the Manage catalog link in the IDHub dashboard), then the following page would be displayed:

Let’s say you want to edit the application “ADP” shown in the list. Click on the edit icon, and this will open up the application wizard in the edit mode as shown below:

If you want to edit the basic details like: search Keywords, owner, approval workflow etc. then in this screen you can edit those attributes and click on the next button.

The next screen shows the attributes for the application. If you want to edit the existing attributes, then click on the edit icon displayed for each attribute in the right hand side of the page. When you click on the edit icon, the attribute details are editable as shown below. You can change the application field name, IDHub user field name, data type as well as other details like: required or not required, multi value or no multi value, recon key or not, account name field etc.

You can also change the sync direction of the field. When you click on the small arrow at the top, following is displayed:

There are basically four sync directions:

  • Application to IDHub only.
  • Bi-directional Synchronisation.
  • IDHub to Application Only.
  • No Synchronisation.

You can go ahead and choose to change the sync direction, and after making all the changes, you need to click on the save button. After making the required edits, click on the submit button. Then the changes or edits made in the application will go through the workflow cycle of the application, and once that workflow is completed the changes made will take effect.

Editing Repercussions​

  • Existing open requests and tasks.
  • Account Attributes of new and old accounts.
  • Recon.
  • Other user accounts.

Existing Open Requests Or tasks​

Open Requests in Old WorkflowRequest generated in New WorkflowEffect on Old open requests / Tasks
The application’s old workflow was say for example: Manager Approval. There is already a open request with manager approval workflowApplication is edited and the workflow of the application is changed to Group Approval Workflow.IDHub would ask the user at the time of workflow change, whether he would like to withdraw all open requests / tasks. If the user clicks on YES in the pop-window, then all open requests would be withdrawn and tasks would be cancelled. Else, no change will be there in the old open requests/tasks.

Effect of Editing Account Attributes on New And Old accounts​

  • Old user accounts would not be affected.
  • New user accounts would have the the updated attributes.

Effect of Editing Account Attributes on Reconciliation​

Reconciliation would run as per the updated attributes, and it will update the existing accounts as well.

Best Practices​

  • Changing or reconciliation key is not advisable.
  • Sync direction while setting up the application:
    • Define a source of truth.
    • The Source of truth can be either IDHub or target system.
    • Then you need to define while creating the application, that whether attribute will be created in IDHub or not, which basically means you decide whether the attribute is going to be synced or not.
      • Example Scenario: Payroll info in an HR system, typically don’t want the payroll info to be shown anywhere else except the HR system which is your source of truth. Then in this scenario, you need to either make sync direction off for the payroll attribute while creating the application in IDHub or you do not keep the attribute altogether in IDHub.
  • Next you need to think about what are the scenarios where new attribute can be inserted into IDHub or not inserted.
    • Example Scenario: Let’s say all documents that is shared in your organisation, all documents should have a documentID and you need to insert the documentID attribute in systems. In this case while setting up the application you can make the sync direction of documentID attribute from target system to IDHub.
  • Sync direction is highly affected on attribute change.
    • Example Scenario: Application has an attribute email address and say that is the unique key. Now if email address is changed in the source of truth and let’s say that your target system is the source of truth. Then ideally the sync direction should be from the target system to IDHub. Therefore, you need to consider your “source of truth” while changing the sync direction, because depending on the source of truth, it will be determined which systems would be updated when the attribute is changed. This is typically called attribute-based Access Control, which lets you take a very granular look at the data requirements before users are able to make access requests
    • Example Scenario 2: Application has an attribute city. And you do not want to update the target system from IDHub, then you need to take care that you do not choose such sync direction.