Interested in using ION to update IFS email address & federated ID after GHR provisions a new actor upon hire. Has anyone tried this reading a flatfile from Azure and formatting an IFS_User_Bod to update the email addresses?
Thanks
Stan
We have a solution for dealing with these types of integrations when GHR is considered the system of record for user data. To start how is the GHR user data being exchanged with customer for internal onboarding of the new hire in GHR? I assume you are referencing that a new hire does not have a corporate email address defined yet and that is what you want to update. You should be updating GHR with the new email and then let that flow via BODs to IFS, this can be done via GHR APIs. If you want to populate the federated ID in IFS you need to modify the default LandmarkMT to IFS dataflow to transform the process.SUM BOD to include federated ID, we suggest using actor ID which should equal employee ID which should be stored in Azure AD. This allows for using a unique never changing attribute for identifying a user after SSO. I would strongly suggest working with Infor services to help architect the solution you require.
Thanks for your reply, Mr. Hollier. Additional background:
We use GHR provisioning to create an actor and assign default security roles by position in response to the HIRE action with Employee ID mapped to Actor ID within the ION sync. The Azure email address is created by a different group, so HR assigns their best guess for what the company email address will be during the Hire process. We have an IPA workflow that executes daily alerting the Azure group of HR hires & terms. We want to add a process to update the Azure company email address for the benefit of GHR and the email address and federated ID in User Management.
Are there caveats when updating an existing Federated ID and Email address in User Management?
If the work email address gets updated in GHR for a user that should already get reflected in IFS ( user management ) from the process.securityusermaster BOD published by GHR and consumed by IFS. If you want to start using Federated ID for SSO purposes then as mentioned that default data flow in ION needs to be modified so that the Actor ID ( employee ID ) is 'mapped' to the Federation ID in the BOD consumed by IFS. When making this change in SSO then you modify the federation on the Infor side to use Federated ID as the lookup value and your IdP ( Azure ) needs to send the employee ID as the name identifier claim on the SAML response after sign on. When you make this change you must ensure that all accounts in IFS have the federated ID populated and matching their employee ID stored in Azure which should be the Actor ID. You can easily do this by exporting IFS users, modify the CSV and then importing back into IFS. The federated ID is only used for SSO purposes and is not leveraged by applications. A change in email address shouldn't be a concern as well, GHR updates IFS, IFS then publishes a sync.securityusermaster BOD which would feed to other applications within the tenant.
If you are looking for a way to update the GHR email address for a user via automation then there are GHR APIs that can be leveraged to update the email address.
Once again, thanks for your insight and advice. Appears we can create an IPA process to read GHR employee existing UseforWork Email address and compare it with an email address read from Azure, then make an update when Azure is different.
What events cause a SUM Bod to be published in GHR and launch the LandmarkMT_IFS_User_Bod ION flow?
