When migrating access profiles between environements using the SP-Config APIs (/beta/sp-config/export and /beta/sp-config/import), the import process (sending the access profiles to the desired environmeent) will silently drop access profiles and return “No objects found to import” error. This is caused by an inconsistency in how the SP-Config engine generates and reads owner references.
The Bug:
-
The Export Behavior: When SP-Config exports an access profile, the backend engine populates the
"name"key inside theownerblock with the Identity’sdisplayNameattribute (e.g.,"name": "John Doe") to make it human-readable, rather than using the actual technical Identitynameattribute (e.g.,"name": "JDOE"). -
The Import Behavior: When the SP-Config Import engine reads this JSON file in the target environment, it performs a strict lookup to map the owner. However, it searches the target database’s technical Identity
namefield using thedisplayNamestring provided in the JSON. -
The Result: The lookup fails because it is searching for “John Doe” inside the
nameattribute instead of thedisplayNameattribute. Because an Access Profile must have an owner, the engine aborts the creation of the Access Profile entirely.
Current Workaround:
To successfully migrate access profiles via SP-Config, I used “query”: f"displayName.exact:\“{name}\”" (displayName instead of Name) in python script, in postman you gotta manually overwrite the owner.name fields with the exact technical Identity name (e.g the UID) from the target environment.