Newbie here. Is there any way to import a Workflow object into ISC? For instance, I want to create 10 workflows in Sandbox, add them to a Git repository, and then use a pipeline to deploy them to Production. Is that possible for Workflows (or for other objects that SaaS Configuration doesn’t support)?
Thanks!
Yes, it is possible! You can export workflows from one environment and import them in another, you’d just have to edit the JSON to correct any IDs that are different per environment (e.g. the workflow owner’s identity ID, or any ID that is environment specific) before importing.
To do this, you’d need to download the workflow, there’s a download script button when you click on a workflow:
Then like I said, edit the JSON as needed, and import in next environment by clicking “New Workflow” and selecting “Start with a JSON File”:
Just adding to an already wonderful reply from @vkashat
Check out the Configuration Hub.
You can create backups from your sandbox and import them directly into the prod tenant (direct connection!). Workflows, sources, roles, transforms, etc. All these can be migrated using the Configuration Hub.
Matt
Thanks, but I’m looking for running all of this through a Git repo. I want to add the JSON object in a repo and then deploy it via a CI/CD pipeline and import it into Prod using the ISC API.
Deploying via CI/CD such as Jenkins is not possible at this time. Only export from sandbox and import in production is possible at the moment.
You can probably make use of the APIs that the configuration hub uses:
I used to use these APIs for migration before the Config Hub UI was released. They support export and import.
Yes, understood. But this is my use case:
Export JSON object from Sandbox
Add object to Git repo
Deploy that object via a CI/CD pipeline to Production
Is this possible for a Workflow object? If so, how?
Sorry, my reply got messed up in the order of the comments.
So it sounds like my proposed flow is possible… The doc that you linked is a bit confusing. Which one would I used to get a Workflow object?
Thanks!
ISC is not like IIQ. It’s entirely managed by Sailpoint in the cloud. Your case is applicable for IIQ only where your organization has it’s own customized code base, which is deployed in organization servers. Any change can be deployed with CI/CD pipeline in case of IIQ, but it’s not possible with Idnow. IIQ is managed entirely by your organization and you can customize and deploy it in your own way, but ISC is in sailpoint’s server and you can’t deploy with CI/CD.
While I’m not using CI/CD, I do store configurations in a git repo.
Whatever automation looks like for you, exporting and importing workflows via API could look something like the following:
Since we’re only talking about workflows, this documentation may be more applicable:
Matt
Thanks for the additional detail.
In Postman I tried to retrieve the Workflow using /beta/workflows/:id, but I get this error:
{
“detailCode”: “Forbidden”,
“trackingId”: “30aca97c27d54883858f8c9c338f6320”,
“messages”: [
{
“locale”: “en-US”,
“localeOrigin”: “DEFAULT”,
“text”: “Forbidden”
}
]
}
My client ID has this access:
idn:icons:read,sp:scopes:all
And I am able to access other endpoints and retrieve data. For instance, /accounts works just fine.
I am also not able to get all workflows from /workflows. I get the same “Forbidden” error as above.
One issue with /workflows/:id is that I don’t know how to get the workflow ID. I can’t seem to find it anywhere in the UI.
Also, why can’t I use v2024 instead of beta for the API version?
Thoughts?
From the documentation: “Forbidden - Returned if the user you are running as, doesn’t have access to this end-point.”
The token you’re using, what user level is associated with it? I believe workflows are only accessible to a full admin.
You can get the id from the /workflows endpoint, and filter on name.
Of course you can use the v2024. All I was sharing was an example.
A Personal Access Token (PAT) with sp:scopes:all works for all endpoints, provided the PAT is generated with the appropriate user access level, such as ORG_ADMIN.
You can find the workflow ID in the URL when editing a workflow. For example:
https://yourtenant.identitynow.com/ui/a/admin/workflows/edit/a3ferfrf43rf4f43r343348dbe7873
The string a3ferfrf43rf4f43r343348dbe7873 at the end is the workflow ID.
Alternatively, you can use the following API endpoint to fetch all workflows and extract their IDs:
list-workflows | SailPoint Developer Community
You can use both the v2024 and beta API versions. However, to use the v2024 endpoint, you must include the X-SailPoint-Experimental header in your request and set it to true. For example:
X-SailPoint-Experimental: true
OK, maybe I’m confused on the usefulness of PATs. I have a client id and key pair that I generated but it is not associated with my identity.
Here is the access that it has:
Do I have to use a PAT and give my identity full admin access to make this work?
I tried the experimental header, but that did not make a difference. It looks like that header is not needed for the Workflow endpoint.
I do have scopes:all assigned to my client id, but I don’t have a PAT. Is that what I’m missing?
It’s strange because I can get data back from various other endpoints without a PAT.
For instance, I can get data from /workgroups, but that object requires Admin access, so it doesn’t seem like I would need special access for /workflows.
Refer this link to create a Personal Access Tokens (PAT).
Once you get the client ID and Client Secret, use them in your scripts/Postman.
PAT you generate is always associated with your identity. Scopes you define for the PAT are limited by the access level your identity has. So, if you are not an ORG_ADMIN no matter what scopes you define for the PAT you generated, it will not have access to end points related to workflows
Thanks everyone. The authorization issue was related to not using a PAT. Once I used a PAT, I could access the /workflows endpoint.
Hi,
While I understand that it is not like IIQ, we still store the configs of the sources/transforms preferably in a source control repo right? If we store it in github repo, and deploy the latest source changes via API using actions, is that not an ideal solution?