We have created the workflows in NERM to support the onboarding of new non-employees. We are now planning to move these objects to the higher environments and eventually to Production.
Currently, there are no existing NERM objects in Production, so this will be the initial deployment. Could anyone advise on the recommended steps and best practices for migrating the following objects?
Create Workflow
Update Workflow
Profile Types
Please let me know if there are any prerequisites, dependencies, deployment order requirements, or other considerations we should be aware of before moving these changes to Production.
@Pradeep979 - There are a few number of prerequisites, dependencies, deployment steps, and recommendations which we have to consider.
Prerequisites
Generate a NERM API token (Admin > System > API Settings) required for tenant migration.
Moving forward, create and modify these objects only in your lower tenant, not independently in both each one is given a unique UID and GUID when created, and creating the same object in Production manually would give it a new GUID, resulting in future migration problems for that object.
Migration of Non-Employee Profiles is impossible. If you have workflow actions or conditions that use a certain profile (e.g., an approver, sponsor, org owner, etc.), create that profile in Production manually, then edit the exported JSON file replacing the UID with that of the corresponding Profile in Production.
If workflows contain any API actions, make sure they reference Production URLs and tokens prior to migration. Same applies to any hardcoded URLs in notification templates.
Deployment order as per SailPoint’s own guidance
Profile Types - SailPoint recommends importing foundational objects like profile types and user roles before workflows. SailPoint Profile Types carry their Attributes/Forms/Pages as dependents.
Lifecycle User Roles (only if new/changed) - Workflows reference the roles allowed to run/access them.
Create Workflow - Depends on the Profile Type from step 1.,
Update Workflow - dependency; import after Create Workflow.
Important Note: Import does not delete any data therefore, if you delete an attribute or step in the DEV instance, then you must also do so in the PROD instance because Import cannot do that for you. With respect to the banking customer, log all the Export JSONs with their respective import job ID and date, as this is what the auditor will ask for.
So when using configuration import, should you or could you archive the OLD Production Attribute, Workflow, profile type and then import the one from lower environment to eliminate any attribute/step duplications?
If you are no longer using those configuration objects - archiving them is certainly helpful to keep the space “clean”. There isn’t necessarily a technical reason requiring you to archive the objects, but it can get confusing if you have a bunch of old items that are no longer in use. For example, if you have similarly named attributes, but one of them is out of use - archiving it would ensure that you do not accidentally select it in a configuration
So I imported about everything I could remember changing into our Pre Production environment and spot checked a lot of it, ran a new non employee request, a deduplication test, and, a New student request which all were successful. How can I VALIDATE that all changes over the last 8 months to a year were migrated? Do I have to compare ever json with UAT? That would be a painful process.
If you have already run through testing where workflows work properly, profiles are created/updated with the right data, and there are no errors - then generally you should be assured that you are not missing any parts of the configuration.
To note, that not ‘all changes’ from the past are included when exporting a configuration. The export process just takes whatever is currently configured for the object you are exporting - it does not include the audit history of that object..
We don’t have an automated process to validate configurations between tenants -that is still a manual process at this time. When exporting an object, a Workflow for example - it will include everything utilized by that configuration in the JSON file. So, you don’t need to export the workflow and the profile type and all the attributes, etc… Everything used by the workflow is bundled together.
Personally, when I have done large tenant-wide imports (such as all new Profile Types, workflows, notifications, etc), I will do a manual verification between tenants. I open the SB tenant in one window and the Prod tenant in another, side by side on my monitor. Then, I manually go through and check if all objects are configured the same between tenants - including workflow actions, profile type settings, notifications, value builders, portals, user roles, etc. It can certainly take half a day or longer, but it does verify that nothing was missed or broken.
On smaller imports, like just a single workflow or otherwise - I will perform a quick visual check that all the actions/conditions are in the right order and run through a few tests to ensure its working as expected.