A workspace is a working space generally defined around the scope of a client's project — a business department, a theme, a project or a data domain. Its settings are the workspace administrator's to tune.
User administration at the workspace level and customizing workspace screens are covered in complementary articles.
What is a workspace?
DataGalaxy's purpose is to operationalize data management. The platform is built to map out scopes that are easy to grasp — so rather small or well-defined ones.
That said, starting small doesn't mean:
- Being the only initiative: several mapping initiatives can run at the same time.
- Covering the entire company: maturity and needs (granularity, depth, etc.) differ from one initiative to another.
- Never having other, completely different domains down the line.
DataGalaxy has two levels of management:
- Client spaces.
- Workspaces — that is, working spaces generally defined around the scope of the client's project(s).
The point of being able to create one or more workspaces is to organize data governance by business unit or theme, and move forward step by step with a reasonable amount of data to handle per project. You can create workspaces:
- By business department: marketing, HR, finance, etc.
- By theme: GDPR compliance, etc.
- By project: building a new data warehouse, etc.
- By data domain: customer, supplier, product, etc.
Workspaces exist to make teams more productive. They let you manage:
- A team, where each member has a role and permissions that can evolve as needed.
- Screens, where the administrator can build data representations suited to the domain's needs.
- Integration with collaboration tools.
Who can access these two spaces?
The point of a workspace is to collaborate within a restricted scope. Designating a single administrator is still worthwhile, because you need to:
- Avoid everyone editing screens that should benefit the whole team.
- Manage different permission levels depending on each person's maturity.
- Speak with one voice to client-space administrators for anything inherited from the client space: creating attributes, enriching tags, inviting users, etc.
Depending on how complex your use of the platform is, it can be worth separating this role from the client-space administrator role — but that's not a technical requirement.
Access is reserved for users designated as administrators. Non-administrator users don't see either of the two buttons.
What are the inheritance rules between the client space and the workspace?
Settings customized within a workspace don't affect the client space, or other workspaces.
This is customization of a single workspace, where the administrator can, for example, add or remove fields to make their workspace more relevant to their needs.
The diagram below summarizes the main characteristics of the client space and workspace, and the one-way inheritance relationship between them: