[codex] Add workspace governance guidance for enterprise onboarding

platform-cloud/docs/credentials/data_repositories.md

@@ -38,6 +38,10 @@ Azure Blob Storage are prefixed with an Azure icon and `az://` in Data Explorer.
 
 Add the contents of the **Service account key** JSON file. GCP object storage buckets are prefixed with a GCP icon and `gs://` in Data Explorer.
 
+For enterprise onboarding, it is usually best to create a dedicated GCP service account for each workspace or team boundary that needs independent access control, then grant that service account access only to the required buckets or prefixes. Store that credential in the same Seqera workspace where the data will be browsed or launched from.
+
+If a workflow spans more than one cloud provider, keep the provider-specific credentials in the launching workspace and verify that the selected compute environment and work directory are configured for the cloud where the run will execute. Data Explorer can surface data repositories from different providers in the same workspace, but access to each path still depends on the credentials and network access available to that workspace.
+
 ## S3-compatible storage
 
 This includes cloud-provider and on-premise based storage solutions with an S3-compatible API. Examples include [Cloudflare R2][cloudflare], [MinIO][minio], and [Oracle Cloud Infrastructure][oci].

platform-cloud/docs/orgs-and-teams/workspace-management.md

@@ -33,6 +33,17 @@ As a workspace owner, you can modify optional workspace fields after workspace c
 
 Apart from the **Participants** tab, the _organization_ workspace is similar to the _user_ workspace. As such, the relation to [runs](../launch/launchpad), [actions](../pipeline-actions/overview), [compute environments](../compute-envs/overview), and [credentials](../credentials/overview) is the same.
 
+## Workspace planning for larger organizations
+
+For larger organizations, decide your workspace boundaries before you start adding credentials, data links, and compute environments:
+
+- Create separate organization workspaces for teams, business units, or projects that need different cloud credentials, data-access rules, or compute defaults.
+- Use [teams](./roles) as the default way to grant access, and reserve named participant assignments for exceptions.
+- Use shared workspaces when you want to centralize reusable pipelines or compute environments for multiple groups, while still letting each consuming workspace keep its own participants and day-to-day operations.
+- Keep workspace credentials aligned to the data and infrastructure that the workspace is expected to operate. Avoid reusing a single broad credential across unrelated groups when separate credentials or narrower scopes are available.
+
+This model makes it easier to onboard new groups consistently, audit who can access a given bucket or compute environment, and limit the impact of later credential changes.
+
 ## Workspace settings
 
 Select the **Settings** tab within a workspace to manage credits, Studios settings, workspace labels, and edit or delete the workspace.