Hi Team, we have recently migrated over from a trial account to a new production environment using the export/import approach gooddata.ai/docs/…/backups#… but now we want to reset the production environment only bring selected workspaces from the trial environment. When trying to restore the original backup of the new production environment I am getting the following error - {"detail":"Some of given referenced 'createdBy' entities do not exist. Not existing IDs: [Identifier(xxxx.xxx)/Organization(xxx)]","status":400,"title":"Bad Request","traceId":"1c7a4c596ebe177e5393c0c45e2099b3"} please note the user and organisation details have been obfuscated.

Resolving the createdBy 400 Error on Workspace Restore This is a known issue with the declarative API: when you PUT a workspace layout, all

createdBy

and

modifiedBy

references are validated against users that actually exist in the target organization. If the layout contains references to users from a different organization (e.g., from your trial environment), the request fails with the 400 error you're seeing. [Workspace declarative API] Recommended Fix The cleanest solution is to exclude author/editor metadata when exporting, using the

exclude=ACTIVITY_INFO

parameter. This prevents invalid user references from being included in the payload. [Extended Metadata] Step 1 – Export the workspace layout without author metadata:

curl -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -X GET \
  $HOST_URL/api/v1/layout/workspaces/{workspace-id}?exclude=ACTIVITY_INFO \
  > workspace-backup-without-authors.json

Step 2 – PUT the cleaned layout into the target workspace:

curl -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -X PUT \
  -d @workspace-backup-without-authors.json \
  $HOST_URL/api/v1/layout/workspaces/{workspace-id}

When reimported this way: [Extended Metadata] •

createdAt

will reflect the upload time. •

createdBy

will be set to the user performing the PUT request. If You Already Have a Backup File With Stale References If you're working from an older backup file (not a fresh export), you have two options: 1. Re-export fresh from the source using

exclude=ACTIVITY_INFO

as above. 2. Manually edit the backup JSON to remove or replace all

createdBy

and

modifiedBy

fields that reference users/organizations not present in the production environment. [Object authors and editors] Important Reminder for Cross-Organization Migration Workspace layouts are not directly portable between organizations without manual changes. Beyond user references, also ensure: [Importing a Workspace] • All

dataSourceId

values reference data sources that exist in the production organization. • The target workspace already exists before running the PUT. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@kapa.ai I have removed the

createdAt

and

createdBy

references and still get the same error

The knowledge sources mention that

modifiedBy

references are validated in the same way as

createdBy

. It's worth checking whether your backup JSON still contains

modifiedBy

(and corresponding

modifiedAt

) fields referencing users from the trial/source organization — these would trigger the same 400 error. Make sure you've removed all four author/editor fields: •

createdBy

•

createdAt

•

modifiedBy

•

modifiedAt

The safest approach is to re-export using the

exclude=ACTIVITY_INFO

parameter, which strips all of these fields in one go rather than removing them manually: [Extended Metadata]

curl -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -X GET \
  $HOST_URL/api/v1/layout/workspaces/{workspace-id}?exclude=ACTIVITY_INFO \
  > workspace-backup-without-authors.json

If you cannot re-export from the source and must work from the existing backup file, I'd recommend doing a global search across the entire JSON for any remaining user identifier patterns (e.g.,

"type": "user"

) to catch any stale references you may have missed. Beyond that, the knowledge sources do not contain enough information to diagnose further causes of this specific error. If the problem persists after removing all author/editor metadata, I'd recommend opening a support ticket with GoodData, sharing the workspace ID and the exact payload you're PUT-ing so their team can investigate further. [Community thread] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

Hi Keith, The most likely gap: modifiedBy and modifiedAt are validated the same way as createdBy, so if those are still in the JSON referencing users from the trial org, you'll get the same 400. It's also easy to miss a reference doing this manually, since these fields exist on every individual object in the layout (each dashboard, metric, insight has its own createdBy/modifiedBy), not just once at the top level. Rather than continuing to hand-edit the JSON, I'd suggest re-exporting the workspace fresh from the trial with the activity metadata excluded entirely: GET {trial_host}/api/v1/layout/workspaces/{workspace-id}?exclude=ACTIVITY_INFO Then PUT that cleaned file into production as-is: PUT {prod_host}/api/v1/layout/workspaces/{workspace-id} This strips createdBy, createdAt, modifiedBy, and modifiedAt across every object in one pass, so nothing gets missed. On import, createdBy is set to whichever user runs the PUT, and createdAt reflects the upload time. If you still hit the same error after a fresh export like this, could you share the exact error detail and traceId from that attempt? That'll tell us specifically which reference is still unresolved rather than guessing. Also, a heads-up given what you ran into last week on the full org migration: if this ends up requiring you to create any users in production, please add them through the standard "Add User" invite flow rather than carrying over the authenticationId from the trial - that mismatch is what caused the login issue you hit before. More detail here: - Workspace Declarative API - Object Authors and Editors: gooddata.com/docs/cloud/create-workspaces/objects-lifecycle - Create and Restore Backups - Migrate to Another Environment: gooddata.com/docs/…/backups#…

Thank you @Shamil Akhmadyshev. The only thing is that we actually want to clean up the production environment and only want to bring specific workspaces from the trial environment. The organization export brought quite a few things that we don't need in production the environment. Is it possible to have the production environment reset at all?

There's no self-service "reset" for a whole org - only deleting workspaces/users/data sources one at a time. Better fix: don't use the org-level export/import at all. Restore just the workspaces you want, one by one: GET {trial_host}/api/v1/layout/workspaces/{workspace-id}?exclude=ACTIVITY_INFO PUT {prod_host}/api/v1/layout/workspaces/{workspace-id} This only brings in that workspace's own layout, so none of the extra org-level stuff comes along, and it also avoids the createdBy/modifiedBy error from before. You'll need to recreate each workspace's data source connection separately, since credentials aren't included in the export.

Ok. Thank you. I will do a manual clean up then import the workspaces as you suggested

Happy to help! Let us know if any further assistance is needed.

Hi @kapa.ai after running the import for original organization layout into our Production environment there seems to be an issue with users and we are not able to log into either the trial environment or the production environment. Can someone please assist?

This is a known issue that can occur after migrating an organization using the declarative API. Here's what's likely happening and what you should do: What's Likely Happening When you import an organization layout, the OIDC client secret is not included in the exported layout. If the

oauthClientSecret

field is missing or invalid in the target environment, users will not be able to log in. [Migrate to Another Environment] Additionally, after environment migrations or authentication configuration changes, users can end up with a missing or broken

authId

— their account exists in GoodData but is not properly connected to the authentication layer, causing: • "Invalid username or password" errors • No password reset emails being delivered Recommended Steps 1. Check the migrated organization layout — Verify that the

oauthClientSecret

for your IdP was provided in the JSON before the PUT request. If it was left blank or used a placeholder, authentication will not work until it is configured. [Migrate to Another Environment] 2. Contact GoodData Support and provide: ◦ Both hostnames (trial and production environments) ◦ Affected users' email addresses ◦ A description of the migration you performed and the symptoms (login failure on both environments) ◦ Ask them specifically to: ▪︎ Verify the OIDC/IdP configuration is correct in both environments ▪︎ Check whether affected users have valid

authId

values and fix any that are missing or mismatched 1. After Support confirms the fix, have affected users go to the login page, click "Forgot Password?", and use the reset link to set a new password. > Important: There is no self-service way to repair missing

authId

values or broken OIDC configuration — these require GoodData Support to resolve on the backend. [Community thread] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.