How do we have multiple people work in the MODEL at the same time? Currently, whoever saves last overwrites the other persons changes.

GoodData’s modeler and declarative APIs do not provide true concurrent editing with automatic merge; the behavior you see (last save wins) is expected, and the knowledge sources do not describe any built‑in conflict‑resolution for multiple users editing the LDM at the same time. What is available are tools and practices to reduce the risk of overwriting each other: 1. Use impact analysis in the Modeler UI The Model changes / impact analysis view shows what objects are affected before you save, so each person can review the impact of their own changes before committing them. However, this still doesn’t merge parallel edits; it just helps you understand consequences. [Monitor changes] 2. Adopt an “Analytics as Code” / CI/CD workflow Instead of multiple people editing the LDM directly in the UI, you can manage the LDM and analytics model as code in Git and deploy via pipelines. Git then handles merge conflicts between branches, and GoodData’s validation can be run in the pipeline: ◦ Use Git pull requests and merges to resolve conflicts between contributors. [CI/CD discussion] ◦ Use GoodData CLI / Python SDK and relation validation (e.g.,

X-GDC-VALIDATE-RELATIONS

, LDM extension checks) to ensure the merged model is consistent before deploying. [CI/CD discussion; Relations check] 3. Process / coordination workaround Since there is no documented real‑time collaborative editing, teams typically: ◦ Coordinate who is editing which part of the LDM and when (e.g., “lock” by convention). ◦ Or move most changes into the code‑based pipeline and treat the UI as read‑only or for small, isolated tweaks. Because the docs and Slack threads do not mention any feature like “multi‑user locking” or “live collaboration” for the LDM, the safest approach today is to rely on source control + CI/CD for collaboration, and avoid multiple people editing the same workspace model directly in the UI at the same time. 👍 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.

1. Parallel edits - this is exactly the case i am referring to. Also STALE edits - if someone has the model open, without refreshing, their model is STALE and will overwrite new changes, even if they weren't in parallel. 2. Analytics as code would be great - but

gd cli

doesnt support child workspaces, so this isn't an option. This would be the best solution.. please gooddata! 3. Coordination workaround - this is like working in the 90s using svn or rcs to lock files to work on them. This would actually solve the problem - if we could LOCK the workspace while someone edits, it would prevent overwriting. Please enable this! Coordinating with people directly (talking to one another) is a really bad solution for teams greater than 1 person - optimistic locking is not effective.

Hi Matt, At the moment, locking a GoodData Cloud workspace (or its LDM) to a single editor is not an available feature. However, as a workaround, you can consider using workspace hierarchies so that only the parent’s LDM is editable and child workspaces are read‑only consumers.As explained in our documentation on Workspace hierarchy. I will go ahead and submit this as feedback to our product team. We cannot provide an ETA at the moment as our engineers are working on critical tasks. If you would like this to be treated as priority, Feel free to reach out to your account owner @Thiago Alves.

we have a workspace hierarchy. we'd love to manage it via code, but

gd cli

doesn't support hierarchies.

Hi Matt, while GoodData Cloud doesn’t support true concurrent editing/locking in the Modeler (so “last save wins” and stale tabs can overwrite changes). The recommended way for multiple people to collaborate safely is an “Analytics as Code” CI/CD workflow, where the model and analytics are managed in Git and deployed via pipeline. Recommended CI/CD approach: 1. Treat the parent workspace as the single source of truth All model/analytics changes are applied to the parent, and child workspaces consume them via hierarchy. 2. Store the workspace layout in Git Use the declarative workspace layout (export the parent workspace layout to files), commit to a repo, and use PRs to merge changes safely (Git handles merge conflicts instead of the UI overwriting changes). 3. Validate + deploy via pipeline In CI, validate the merged layout; in CD, apply it back to the parent workspace using the declarative APIs / Python SDK. Please refer to the following documentation for more guidance: Declarative interface (foundation for “Analytics as Code”): https://www.gooddata.com/docs/cloud/create-workspaces/declarative-interface/ Workspace hierarchy (parent changes propagate to children): https://www.gooddata.com/docs/cloud/workspaces/workspace-hierarchy/ Blog: Automate analytics using CI/CD: https://www.gooddata.com/blog/automate-data-analytics-using-ci-cd/ GitHub example repo (layout-in-Git + pipeline example): https://github.com/gooddata/gooddata-git-workflow-example Hope this helps!