Have you ever wished that there was a way to update usernames automatically, only to realise that usernames are not available to the Business Rules Engine?
Today, I am delighted to show you an Integration that I have built to automate updating the username of my instance. The specific use case I have is in a hybrid implementation, where there are many “Rehires with New Employment” performed. In this case, the username for the inactive record needs to be updated so the previous username can be used for the new employment (there are some other follow on activities that necessitate this and integrations to update the username with the Business Email, but not going into all the detail).
So the need is to update inactive users in Employee Profile. If you are not using an API upsert by including the parameter “processInactiveEmployees=true“ in your middleware, you are left with the only other option, which is the Integration Centre. The only problem is, the Integration Centre cannot update inactive records. Well, until the H2 2020 Release that is!
With this release, it is possible to create an API Profile and assign the profile in your integration. So to start off with, navigate to the Admin Tool > Manage API Profile Option. Here you can create a new profile, and in my use case, I specifically selected the Process inactive Employees checkbox:
API Option Profile Settings
Now that the API Option Profile is created, I can start creating my integration in the Integration Centre. Start off by setting the integration type as SuccessFactors Source and Destination, to allow you to use ODATA v2. I have then also selected that it should be scheduled, as I will then run this periodically to update the username for any terminated employees.
Integration Type selection
From here, search for and select your starting entity Username (username) in User.
The Integration Centre has a wizard-style interface, allowing you to complete an integration step-by-step. First, you will complete the Options, i.e name of the integration, optional description, and enabling server-side pagination if you are querying large amounts of data to give a performance boost.
Then on to the Configure Fields step. This is where you map your fields to populate, but furthermore, you are also able to set calculated fields and values. In my use case, I want to update the username by prepending it with an “i_”. That will be a calculated column. There are three additional fields that I must map since they are required fields, namely, userId, gender, and status. For these three, I simply map the fields to be populated with the existing values:
The Operation is set to Update/Merge, which updates only the fields provided and leaves other field values intact. With the H2 2020 Release, it brings in a new field, API Option Profile ID, which is where you capture the API Option ID created in the initial step.
Now on to the Username field. As mentioned, instead of mapping this field, we will create a calculated field.
My calculation I set to IF/THEN/ELSE to ensure that only the username of inactive employees is updated and that active employees’ username remains the same.
You can check the Calculation Trace to see if this yields the desired results. Once you close the calculation, you are able to preview the records and your results should look a little something like this:
Preview of Results
Employees with a status of “t” (active) has the result of the username remaining unchanged, while employees with a status of “f” (inactive) are prepended with i_.
Now proceed to the Filter and Sort step, and set the following:
- Use the Status in User field, and set the filter equal to “f” (inactive), since you do not require to update username for active employees.
- Additionally, exclude usernames that start with “i_”. This will ensure that you do not end up updating inactive users with each schedule that could lead to “i_i_i_i_ENeal”.
- Lastly, I have also included Employee Status from EmpJob (Job Information) and set it as equal to 4600 (in my instance), the optionID for Employee Status “Terminated”. This will ensure again that only when someone is terminated, they will be included in the integration update.
As I will be scheduling this integration to run periodically, it is necessary to specify a time-based filter. In my case, I specify that only records that have been modified or are effective since the last run time will be included in the next integration run.
Now move to the Scheduling step, where you can set the frequency of the integration. Also courtesy of H2 2020 Release, you can now set the maximum number of executions to 12 and specify the interval of hours.
Lastly, you are ready to Review and Run. Here you can trigger a one-time run, and set the recurring schedule.
Your integration will now run at the intervals set, and update the usernames of terminated employees.
This method can be modified to suit your needs, perhaps create a new username for new hires. It is a very flexible method of updating information in your instance.