Hello, we have a couple of questions on what we are doing and planning to do with GoodData are you able to provide some feedback on the following What is the best method to backup all our customer's workspaces? Is it wise for us to be managing our own backups via the APIs? The Dashboard Sharing feature - can you clarify the API call for this as it seems to be missing the share permissions property? https://www.gooddata.com/docs/cloud/api-and-sdk/api/api_reference_all/#operation/manageDashboardPermissions We are planning on cloning a generic workspace into each customer workspace whilst mutating the various users, filters, and data source pointers for each customer. We have been using the various Entity API's to clone in each element of a workspace (metrics, visualisations, etc) and patching these with the correct Ids. We have since noticed the Declarative APIs - can we simplify our cloning process by applying the same GET-PATCH-APPLY cycle with a single call? Is this cloning process typical of other customers and if not are there better options for applying canned dashboards across all our users? Can you deploy a dashboard into another workspace from within the GoodData UI? We were planning on performing this step via a devops pipeline is this unattended approach typical of what other customers are doing? When making updates how do we ensure we aren't disrupting customer created dashboards? Can metrics and visualisations be permissioned to prevent customers from making changes to our predefined settings but still allows them to use and build on top of them? Can metrics contain circular references, do we need to guard against this when creating metric dependencies?

Hi Toby, Please let me try to address your questions here: 1.) Backup of Customer Workspaces AFAIK, the only method available and commonly used is via API and it is described in the below documentation: https://www.gooddata.com/docs/cloud/manage-organization/organization-api/backups/ 2.) Dashboard Sharing API I was reviewing the API documentation and the related API calls and I can confirm that you are correct. There is indeed a mistake in our docs. More specifically - the `"permissions"`is missing in the Request sample payload. The example payload should look like this:

[
  {
    "assigneeIdentifier": {
      "id": "example.namesdfsifsdfjsodf",
      "type": "user"
    },
    "permissions": ["SHARE"]
  }
]

(for specific user or userGroup) Or this:

[
  {
    "assigneeRule": {
      "type": "allWorkspaceUsers"
    },
    "permissions": ["EDIT"]
  }
]

(for all workspace users) I’m raising this issue internally and we will fix the documentation as soon as possible. 3.) Cloning Workspaces I can confirm that the procedure for cloning a workspace is either usage of declarative APIs: https://www.gooddata.com/docs/cloud/create-workspaces/declarative-interface/#WorkspaceDeclarativeAPIInterface-CloneaWorkspace Or alternatively, the workspace can be also represented and managed using declarative YAMLs, should this interest you. https://www.gooddata.com/docs/cloud/api-and-sdk/vs-code-extension/ 4.) Deploying Dashboards to Another Workspace via UI Unfortunately there is no built-in UI way how to deploy Dashboards to Another Workspace. You would need to use API for that (except for simply using workspace hierarchy where dashboard created in a parent workspace is automatically inherited by its child workspace). 5.) Updating Workspaces Without Disrupting Customers’ Dashboards Could you please elaborate a bit more on this question? What updates are we exactly talking about in this case? 6.) Permissions on Metrics and Visualizations: No, Metrics and Visualizations don’t contain permission setting as Dashboard or Workspace. The available user roles can only distinguishe whether a user can create or manage a metric. More information below: https://help.gooddata.com/doc/growth/en/workspace-and-user-administration/managing-users-in-workspaces/user-roles/user-roles-permissions/ 7.) Circular References in Metrics GoodData does not allow circular references in metrics. The MAQL engine automatically detects circular dependencies and prevents them from being created. But it’s still good practice to manually check for logical loops. While GoodData enforces restrictions at the metric level, unintended circular logic could still arise if you structure dependencies in a way that creates conflicting calculations.

Hi Toby, I noticed your note on how you plan to use GoodData Cloud: > We are planning on cloning a generic workspace into each customer workspace whilst mutating the various users, filters, and data source pointers for each customer. and just wanted to bring your attention to the concept of Workspace Hierachy that is natively supported by GoodData Cloud. I am not familiar with your exact use case, but it sounds like it might be a great fit. How it works is that instead of copying individual objects (or full workspace definitions with layout API), it allows you to set up a hierarchy of parent-child workspaces where the child workspaces automatically inherit everything (data model, metrics, dashboards…) from the parent workspace. Typical setup is that you have one child workspace for each customer. And you manage the core analytics for all of them just once in a single place - the parent workspace. Customers have in their workspaces read only access to all the objects (dashboards, metrics) inherited from parent (with data automatically filtered to just that customer’s data) - and they can (if they have permissions in their workspace) also create custom objects that will only live within their workspace and won’t affect other workspaces. To separate the data for clients, you can either set up Workspace Data Fitlers in your hierarchy (if you have data of all clients in the same table partitioned by a column) or define Unique data source per client workspace (if you have data in different databases). This way, managing a multi-tenant analytical environment can be made much easier, with les overhead and clearly defined what is core and shared and what is customer-specific. I hope this helps, please let us know if you’d have any questions regarding the setup or architecture.

Good Morning @Michal Hauzírek, Thanks for your response re Workspace Hierachy we are exploring this option to simplify our process. There are some additional questions from the development team....

Hi Hayley, great questions. Let me try to answer them for you by topics GoodData CLI While this particular GoodData CLI can be used also without the VS Code for performing automations (once you install it from NPM, you can also use

gd clone

and

gd deploy

and others without the need to use the VS Code itself. However one of its main goals is to translate the API responses from GoodData APIs into the structures used by VS Code plugin. Just note that the CLI and VSCode are currently meant for managing a single workspace only, not the whole hierarchy. As far as I know it does not perform diff merge, but full replace.

gd clone

downloads full current definition of a single workspace and

gd deploy

completely replaces contents of that workspace. It could still be used i.e. to manage the parent workspace, but please note that both the VS Code and this CLI are still marked as BETA and not recommended for production deployment. If you want to automate your production deployments, I would recommend to use the Python SDK that can handle full spectrum of workspace hierarchies etc. (An example of deployment management is described here). It also allows you to get and set declarative configuration of workspace, its part or the whole solution. I would say the best practice would be to use Python SDK to define a declarative setup of a workspace (i.e. from a development workspace/environment where you develop the changes), store it to git/other versioning tool where you can perform diff/merge/approve and then use Python SDK to deploy the changes to production. Performance of APIs The APIs that handle the workspace structure - data model, metrics, dashboards - does not directly work with or contain the data on which the reporting is happening. As far as I know GoodData has many customers with hundreds or even thousands of tenants and the API works fine. Especially when working with the hierarchy, each workspace would only contain objects specific to that workspace, not whole copy of the parent workspace. For performance of the queries (how long it takes to calculate the report) - this would depend on the underlying data source and how the database is structured and optimized - GoodData is generating the SQL queries and executing it directly against that database, plus there is a caching layer that can store results of previous queries. Metrics All metrics and other objects in GoodData Cloud reference each other by identifiers. Cloning should not break any metric relationship. If any change (i.e. removing part of logical model) affects some objects in child workspace, the affected metrics would get hidden. There is a special http header on the APIs “X-GDC-VALIDATE-RELATIONS” that should allow you to check if any objects are broken. Custom attributes By custom attributes against workspace - do you mean by that that apart from the core shared data model inherited from the parent, you would like to extend the data model of a particular workspace with some additional attributes? This is possible by modifying the data model of the child workspace and adding additional dataset there, which is connected (by a M:N edge) to the core dataset’s key. If you would be interested in this particular case, we can share more info. I hope I answered all your questions. Please feel free to ask here in community if you would like to know more.