How to onboard an application/source with only one environment (production) to SailPoint production? I guess every organization will face this situation. We have couple of sources (webservices connector) onboarded in production configured with account aggregation HTTP operation. This is ok till this point. These sources don’t have a test environment. Now we want to implement account disable operation as well. Our inactive lifecyclestate is configured to disable target account. How can we do this without affecting any other functionality in production environment? more so if the disable operation involves some code. Appreciate any best practice suggestions.
Here is what I understand, based on your post. You have ISC configured to disable an identity’s account on a certain source, when the identity’s LCS changes to ‘inactive’. This is a pretty common configuration, so assuming the target source has a connector that supports account disables, I think it will work.
Additionally, provisioning plans are always specific to one identity, so I wouldn’t expect any changes aside from disabling the accounts of the identities with the inactive LCSs.
Is there any additional context or reason to suspect unintended changes to this production source?
TomNimmo, yes it is a standard implementation. But the point in my question was, how can we straightaway make these changes in production environment without testing in sandbox?. Are there best practices followed in such cases. Just to make it more clear,
We have both sandbox and production environments for SailPoint. But lets say an App1 doesn’t have a test environment. Then yes we can connect app1 with SailPoint production for aggregation purposes. But if we need to implement account lifecycle usecases then is it a best practice to still do this on production give the app1 limitations with number of environments.
Unfortunately the best practice is to do this testing in the sandbox before moving it to production. Having a hybrid test/production environment is very tricky, especially with something like LCS changes that happen in your test instance of ISC but which may cause provisioning (writes) to your production of app1.
Is there another (production) source you could use to validate LCS changes? If so, that would be my suggestion.
I am not sure if my answer will help but here is my 2 cents
As mentioned earlier, not having a sandbox or non-production environment for integration/testing poses a risk to the project. What I’ve often seen is the creation of a restricted branch of the non-production environment. For instance, in Active Directory, you could set up a constrained account with read/write access to a specific OU. This minimizes risk while still allowing code to be tested before moving to production.
However, this approach isn’t always simple for certain systems. In those cases, you can either use a specific account-naming prefix or test roles with test entitlements, making it easier to distinguish and clean up test accounts/objects once testing is complete. While some environments can be simulated, there’s always a risk of something breaking when transitioning to the production environment. As far as I know, there’s no specific playbook for this. It’s up to you to determine what works best for your project or organization.
Thanks for the two approaches Sunny. I had that second approach on my mind in some form. Like having a test hire in workday with no position/job there and then use that to create a test identity followed by provisioning/access requests against the sources which don’t have a non-prod environment. There are moving parts in that too but will have to see how it behaves or acceptable to auditors.