I am in the process of exporting a Source configuration from our Sandbox tenant to Production.
I exported the specific Source using VS Code, then uploaded the export through Configuration Hub. I also used Object Mapping to update the Source name (for example, mapping $.name to the new value).
After creating the draft and reviewing it using Edit, I can see that the Source name has been updated successfully. However, I also noticed that the configuration still contains the original ID values from the Sandbox source.
Before I deploy this, could you please confirm whether, for a Source object, I need to remove or clear any additional entries (such as IDs or other identifiers) to avoid conflicts and ensure that the Source is created as a new Source in Production rather than being treated as an existing one?
Also any other best practices on this please let me know
For a Source object, you don’t need to manually strip the ID — Configuration Hub matches objects by name + type during draft creation, not by literal ID reuse, and IDs/owners/dates are already excluded from the comparison logic via the built-in Global Configuration Substitution Rules. So as long as your mapped name doesn’t collide with an existing Source in prod, it’ll be created fresh with its own new ID.
Before deploying, just check the Draft Summary — confirm the Source shows as “New” (not “Modify”). More on that here: Working with Configuration Files.
A few other things to watch:
Source passwords/secret tokens aren’t exported — you’ll need to re-enter credentials manually after deploying.
Map any other environment-specific values too (connection URL/host, owner identity, provisioning rules), not just $.name — see Mapping Objects.
If the Source references custom connector rules, make sure those already exist in prod under the same name — rules can’t be edited mid-migration.
These attributes are not visible in the UI, so I am wondering whether it would be worthwhile updating them as well to avoid any potential confusion, especially since we already have another target source connector in Production that follows a similar naming pattern.
Could you please advise whether leaving these values unchanged would cause any issues, or if it is recommended to replace them before deployment?
connectorName and templateApplication are tied to the actual connector implementation/type registered on the platform (see Customizer Config Object reference) — they identify which connector powers the source, not a user-facing label. I’d strongly recommend leaving these untouched. Renaming them to match “TestAppNew” risks breaking the connector linkage entirely, since the value has to match a valid registered connector definition, not your instance name.
cloudDisplayName is more of a legacy/internal display value from original creation — safe to update for consistency if you want, but since it’s not surfaced anywhere in the current UI, the risk of leaving it stale is purely cosmetic (naming confusion for anyone digging into raw config/API output), not functional.
So bottom line: don’t touch connectorName/templateApplication, optionally align cloudDisplayName if you want tidiness, but it won’t cause deployment issues either way.
I updated the details as per above and made sure, it is only an addition and no change to existing, also no conflicts shown then I went ahead and clicked ‘Deploy Draft’, it took sometime and failed with below error with no useful information as below,
Just curious whether this error indicates any area to look into? Does it evaluate/resolve any token URLs, clientIDs at the time of upload?
as a side note, I did the initial export from VSCode and uploaded and did the mapping etc.
Good question, and to directly answer that part first: no — the deploy process does not validate token URLs, client IDs, or credentials at upload time. As covered earlier, secrets/passwords aren’t part of the export at all, so this failure isn’t connectivity-related.
This exact error (SOURCE_IMPORT_FAILED, generic text with no exception detail) is a known recurring one — see this similar community thread: SP-Config Import Source Import Failed. In that case, the underlying cause turned out to be a duplicate schema attribute name (a case-sensitivity clash like name vs Name in the source’s account schema). Worth checking your exported Source JSON for exactly that — duplicate or near-duplicate attribute names in the schema section.
Two other common root causes to rule out, since Draft Summary comparisons don’t always catch everything:
A source with that name/cloudDisplayName may already exist in prod under a different object, causing a silent name clash at creation time (the Draft “no conflicts” check isn’t always a guarantee here).
A referenced dependency isn’t resolvable in prod — e.g., the source’s owner identity, VA cluster, or correlation config referenced in the JSON doesn’t exist under that same name in production.
Since your exceptionMessage is null (unlike the community example, which at least had detail), this looks like an opaque backend failure rather than a validation error you can fix from the payload alone. I’d suggest:
If nothing more comes up there, this is worth raising directly with SailPoint Support with this exact JSON — a null exceptionMessage typically means something failed server-side that isn’t being surfaced to the API response.
Hello Lalitha. The draft showing Adds: 1 and Modifies: 0 still suggests Configuration Hub planned to create this as a new source rather than update an existing one. The failure seems to be happening later, during the actual import execution.
Before recreating it manually, it might be worth confirming one last time that the draft edits were fully saved. Configuration Hub has a two-step save: after editing the object and selecting Save, you also need to click “Save Changes” on the Draft Summary page for those edits to actually commit to the draft. If that second step was missed, the deploy would run with the original values. The docs call this out specifically.
It could also help to review the exported JSON for any object references that contain only an ID without the corresponding name, especially the owner, VA cluster, and any rule references. Since the export came through VS Code, ID-only references are possible. The docs note that Configuration Hub may not detect an ID-only reference during draft creation, and the issue may only surface when the draft is actually deployed. That would line up with what you are seeing.
Checking the schema attributes array for case-sensitivity duplicates (name vs Name) could be a reasonable sanity check too. That caused the same SOURCE_IMPORT_FAILED error in this thread, though their exceptionMessage clearly identified it, so we can’t assume the same cause here with a null message.
On the token URL and credentials question, I would not take this error as evidence that a connection test happened. Configuration Hub doesn’t include secrets or credentials in its exports, so those would need to be re-entered after the source is deployed. The actual connectivity can then be validated separately through Test Connection.
The disabled Approvals toggle in your Feature Enablement screenshot shouldn’t be related. That only controls whether draft changes need admin approval before deployment.
If the draft was definitely saved and the references and schema look clean, I would suggest opening a SailPoint Support case before rebuilding manually. With exceptionMessage: null and nothing in Deployment Activity, the underlying failure doesn’t seem to be exposed in the tenant.
