> For the complete documentation index, see [llms.txt](https://help.transform.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.transform.ai/general/access-hierarchy.md). # Access Hierarchy ## Overview Transform accounts are structured hierarchically with 3 levels: * **Account** - represents each Transform instance * **Organization** - represents a business/company * **Project** - represents a project within an Organization This structure allows for governed management of Account-wide access, configuration, and context, as well as Organization or Project specific access, configuration, and context. {% hint style="info" %} For internal use, it is common to have only one Organization in an account. For consulting use, each Organization represents a Customer. {% endhint %} **Account setup** influences behavior and workflow across all Organizations and Projects in the account, whereas **Organization setup** influences only that Organization and its Projects, and **Project setup** influences only that Project. For example, [**custom fields**](/administration/custom-fields.md) can be configured throughout Transform: * Custom fields added to Tasks at the **Account level** can be used on Tasks across the entire portfolio of Organizations and Projects * Custom fields added to Tasks at the **Organization level** can **only** be used on Tasks in that Organization and its Projects * Custom fields added to Tasks at the **Project level** can **only** be used on Tasks in that Project Understanding the hierarchy of Transform is key to controlling the user experience and getting the most out of the platform. *** ## Scope Most entities in Transform have a defined '**Scope**'. This describes where in the hierarchy that entity resides and can be used. The scope can be either **Account, Organization,** or **Project.** {% hint style="info" %} **Scope** is defined on entities in fields labeled: Scope, Scoped to, Organization, and Project. {% endhint %} #### Account Scope **Account** scope indicates an entity that is not scoped to a specific Organization or Project, though it may be used at lower scopes. Common examples of account scoped entities are: * Portfolio level [analytics](/analytics/getting-started-with-analytics.md) that aggregate data across an account * Standardized [dashboards](/analytics/dashboards.md) published for use across an account * Internal meetings not scoped to a specific Organization or Project #### Organization Scope **Organization** scope indicates an entity is specific to an Organization and its Projects, which can only be accessed by teammates with access to that Organization. Common examples of Organization scoped entities are: * Specific systems and processes of an Organization * Specific teammates (stakeholders) of an Organization * Analytics created specifically for an Organization #### Project Scope **Project** scope indicates an entity that is specific to a Project, which can only be accessed by teammates with access to that Project. Common examples of Project scoped entities are: * The Project Plan (made up of [Sections](/organizations-and-projects/project-sections.md)) for a specific Project * The Requirements and Test Cases for a specific Project *** ## Display Levels When configuring Analytics in Transform, the **Display Level** determines where the Analytics will display in the account hierarchy. *This is related to but distinct from the Analytics scope.* For example, the Scope and Display Level are defined on published dashboards to determine for whom and where they are available. The following table outlines common dashboarding scenarios with the corresponding configuration of Scope and Display Level:
ScopeDisplay LevelDashboard PurposeExamples
AccountAccountA standard dashboard to see work across all Organizations and Projects. Available to all users in the account.
  • My Work Summary
  • My Team's Work Summary
  • My Customer Portfolio
AccountOrganizationA standard dashboard to see work across an Organization's portfolio of Projects. Available to all users across all Organizations in the account.
  • Company Portfolio
  • Company Activity
  • Company Roadmap
AccountProjectA standard dashboard to see status and metrics within any Project. Available to all users across all Projects in the account.
  • Project Status
  • Project Risks
OrganizationOrganizationA specific dashboard to see activity for a single Organization. Available only to users in that Organization.
  • ACME Co.'s Org Activity
OrganizationProjectA standard dashboard for Projects within a specific Organization. Available to all users in those Projects.
  • ACME Co.'s Project Status
ProjectProjectA specific dashboard to see status and risks for a single Project. Available only to users with access to that Project.
  • Project ABC's Project Status
{% hint style="info" %} Note: The above table does not consider Restrictions that can limit availability of published Analytics for specific users/roles, such as 'Internal Only' restrictions and users restricted to specific Organizations and Projects. {% endhint %} ### Recommended Practices * Publish standard **Account Scoped** analytics at **each display level** to provide users a consistent baseline experience. * Create a mechanism for collecting feedback and suggested improvements to Account Scoped Analytics from users, and incorporate those changes periodically where relevant to all Organizations and Projects in the account. * Carefully manage and communicate changes to Account Scoped analytics since they are used by potentially all users, organizations, and projects in the account. Limit what roles/users have *'Account Scope Publishing'* permission. * Provide Project leaders with roles that have *'Organization Scope Publishing'* and *'Project Scope Publishing'* permissions so they can create and manage personalized analytics for their Organizations and Projects as needed. *** ## Personal Personal analytics and entities can only be seen by the user(s) who created them. Analytics that are **not published** are inherently considered **Personal.** Users with permissions to create analytics but not publish them can only create **Personal** analytics for their personal use, including account, organization, and project scoped views and dashboards. It is common for analytics to start as personal and then be published once refined. Once analytics are published, they are no longer personal. Some entities at the Account scope are also inherently personal: * **Meetings** - if **not** scoped to an organization or project, meetings are only visible to the Attendees. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.transform.ai/general/access-hierarchy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.