> This is part 1 of 2 of the full documentation (pages 1–100 of 156). > The content is paginated: fetch every part to see all of it. > Next part: https://help.transform.ai/llms-full.txt/1 > Page index: https://help.transform.ai/llms.txt # 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 This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.transform.ai/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # Introduction Guides, tutorials, and reference docs for Transform. Transform helps teams accelerates business transformation by maintaining a knowledge base of how their company runs and governing their innovation efforts. For consultants, Transform can be used for delivery across customer portfolios. ## Why we built Transform #### **The Problem** **Building, implementing, and maintaining enterprise systems is harder than it needs to be**. Fragmented documentation, disjointed communication, stakeholder misalignment, and reliance on tribal knowledge increase the risk of delays, overruns, rework, and failure. Without a single source of truth for these programs: * Teammates don't have access to critical context on business processes and systems architecture needed to deliver the best outcomes for the business * Project teams are burdened with the overhead of creating structured plans, trackers, and documentation that end up out of date soon after they are written As a result, entropy compounds in the business and projects. Details are missed, the wrong thing gets built, and knowledge and momentum is lost when someone leaves. **Generic AI tools** lack the context, structure, and governance frameworks to enable aligned and holistic business transformation outcomes. They aren't purpose built for these workflows. **Vibe Coding tools** allow for single-player mode development of software, but don't consider broader implications of the current-state of the business and the process of successfully implementing the solution and managing organizational change. **Generic PM tools** lack the business process, system landscape, and business context and tracking the scope of what is being delivered. They require gnarly customization that rarely works to support or those details end up relegated to spreadsheets or not tracked at all. Though we can write code and build systems faster than ever before, enterprise digital transformation is still incredibly challenging for most businesses. Development was never the bottleneck - deciding what to build, why, and how to implement it always has been where teams struggle and projects break down. #### The Solution Transform replaces the sprawl of tools, sheets, docs, slides, and tribal knowledge with a unified, collaborative platform for teams and agents to work from a single source of truth to translate business objectives into high-quality systems, processes, and outcomes. **It provides consistently unified and governed context** for transformation execution across the business and throughout projects: * The verified business processes, system landscape, stakeholders, decision makers, and the rationale behind it all. * The actual project requirements, solutions, tasks, test cases, and project plan are all transparent and sustainably managed with minimal overhead. Both the business and each individual project to improve it have a 'knowledge graph' that evolves over time. When new details emerge in conversations, code, or artifacts, Transform propagates updates and keep teams aligned on the truth. **Transform was built for collaboration** among the many internal and external stakeholders in the business, from executives to operators, engineers, and consultants; allowing them to co-create the future of their business with shared and up-to-date context and agents embedded into their workflows. The result is more control, speed, and quality in outcomes. # Feature Overview A summary of the core capabilities of Transform. ## Platform Features ### Dashboards & Analytics Transform allows for robust Dashboarding and Analytics. **Explorer** is our Analytics engine that supports highly customizable Views, including List, Board, Gantt, and Calendar views; Pivots; and Charts, including Bar, Line, Area, Tree, Scatter, Radial, Pie, and more. Dashboards are made up of **Widgets** that can be added, removed, and configured to display specific configured Explorers or ad-hoc Explorers specific to the Widget itself. Though you can use the UI to configure explorers and dashboards, you can also use Console to build analytics for you with AI. Read more about [Dashboards](/analytics/dashboards). ### Console & Threads **Console** is the name of our agentic AI natural language interface. Each conversation with Console is referred to as a **thread.** Users can open Console anywhere throughout Transform as a **side-panel** alongside the Transform application UI or go **full screen** for a natural language first experience where preferred. Console is agentic. It can leverage a variety of tools to retrieve data and take action across the Transform platform. It can also delegate specialized tasks to subagents within a thread. Console can also interface with external MCP servers once connected and authenticated, enabling execution across your application stack. Wondering what Console can do for you and how to get the most out of it? Just ask Console and it will guide you! {% hint style="info" %} Note: *Customizable skills are coming soon for improved consistency and quality of responses and actions by Console.* {% endhint %} Read more about [Console](/ai/console). ### Meetings & Notetaker Integrate with your Google, Outlook, or Zoom Calendar to sync meetings with Transform. [Scope](/general/access-hierarchy) the meetings to an Organization and/or Project to build the knowledge base for each, or keep them at the Account level. Have the [meeting notetaker](/ai/meeting-notetaker) join meetings automatically or on demand to capture the recording, transcript, AI summary, and generate Insights to streamline updates to your Organization and Project details, including requirements, risks, tasks, and much more. Read more about [Meetings](/ai/meeting-notetaker). # Access Hierarchy Govern user access and experience within Transform. ## 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) 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) that aggregate data across an account * Standardized [dashboards](/analytics/dashboards) 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)) 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. # Search and Navigation Find work fast with Global Search, filters, and saved shortcuts. ### Overview Search is fastest when location is unknown. Navigation is fastest when Organization and Project context is known. {% hint style="info" %} Screenshot placeholder: top navigation showing Global Search, breadcrumbs, and the left navigation. {% endhint %} ### Key Concepts * **Global Search**: cross-scope search for items * **Breadcrumbs**: scope navigation (Account → Organization → Project) * **Left navigation**: area navigation inside a scope * **Save View**: stored view configuration for repeatable lists {% hint style="info" %} GIF placeholder: `Cmd/Ctrl + K` → type query → open a result. {% endhint %} ### How It’s Used Use this workflow for daily navigation. It reduces time spent searching across scope boundaries. ### Benefits * Faster retrieval of work items and decisions * Reduced errors caused by working in the wrong Project * Repeatable “review lists” through Save Views ### Setup Steps #### Common workflow {% stepper %} {% step %} ### Find the item Start with Global Search. Add filters when results are noisy. {% endstep %} {% step %} ### Confirm scope Use breadcrumbs to confirm Organization and Project. {% hint style="info" %} Screenshot placeholder: a search result row showing a breadcrumb path (Org → Project → Item). {% endhint %} {% endstep %} {% step %} ### Save the route back Create a Save View for repeatable review lists. {% endstep %} {% endstepper %} ### Best Practices * Use Global Search for cross-Project discovery. * Use Save Views for daily review lists. ### Summary Key pages: * [Using Global Search](/getting-started/using-global-search) * [Finding Requirements, Tasks, and Tests](/getting-started/finding-requirements-tasks-and-tests) * [Bookmarking and Favorites](/getting-started/bookmarking-and-favorites) Related: * Get oriented: [Understanding the Interface](/getting-started/understanding-the-interface) * Search with AI: [Console AI Search](/ai/console-ai-search) * Build filtered views: [Working with Views](/getting-started/working-with-views) # Using Global Search Jump to tasks, projects, files, and teammates from one search box. {% columns %} {% column %} **What is covered** * Open Global Search from anywhere * Search by keyword and person name * Narrow results with filters * Use optional operators for precision {% endcolumn %} {% column %} **At a glance** * **Time:** \~2 minutes * **Shortcut:** `Cmd + K` (macOS) / `Ctrl + K` (Windows/Linux) * **Scope:** results limited by access scope {% endcolumn %} {% endcolumns %} ### Overview Global Search is the fastest way to open items across an Account. Use it when item location is unknown. ### Key Concepts * **Scope**: results are limited by access scope * **Type filter**: limits results to a specific item type * **Operators**: optional query modifiers (availability varies) ### How It’s Used Use Global Search for cross-Project discovery. Use it for fast navigation during reviews and triage. ### Benefits * Faster navigation to items and decisions * Reduced context switching across Organizations and Projects ### Setup Steps {% stepper %} {% step %} ### Open Global Search Open Global Search from either entry point: * Select the search field in the top navigation. * Press `Cmd + K` (macOS) or `Ctrl + K` (Windows/Linux). {% hint style="info" %} Screenshot placeholder: top navigation with search highlighted. {% endhint %} {% endstep %} {% step %} ### Search with a broad query Start with a unique keyword. For example: * Task names: `authentication` * Project names: `website redesign` * Teammate names: `Jordan` * Keywords from descriptions or comments: `requirements` {% hint style="info" %} Screenshot placeholder: results list with title, parent, and preview text. {% endhint %} {% endstep %} {% step %} ### Narrow results with filters Add filters to reduce noise when results are broad. Common filters: * **Type** (Tasks, Projects, Comments, Files, Teammates) * **Status** (for task-like items) * **Assignee** * **Project** * **Dates** (created, due, last updated) {% hint style="info" %} GIF placeholder: start broad → add Type → add Status → add Assignee. {% endhint %} {% endstep %} {% step %} ### Open the result and confirm context Open the target result. Confirm Organization and Project context with breadcrumbs. {% endstep %} {% endstepper %} #### Operators (optional) Some Accounts support operators in the search field. When operators are not supported, use filters instead. **Exact phrase** Use quotes to match a phrase, such as `"ERP implementation"`. **Exclude a term** Use a minus sign to remove results, such as `requirements -draft`. **Field-based queries** Patterns vary by configuration. Common examples include: * `assignee:Tracey` * `status:"In Progress"` * `project:"Customer Onboarding"` * `due:today` or `due:overdue` {% hint style="info" %} Screenshot placeholder: query with operators and a narrowed result set. {% endhint %} ### Best Practices * Start broad. Narrow with filters. * Use partial words. `auth` can match `authentication`. * Search comments to find decisions and context. * Check **Recent** items for quick re-entry.
Saved searches (if available) If saved searches are enabled, use them for repeatable triage. For example: * `Overdue tasks (Assignee = )` * `Blocked items` * `This week deliverables`
### Summary Global Search supports cross-scope navigation with filters. Use Save Views for repeatable daily lists. Related: * [Search and Navigation](/getting-started/search-and-navigation) * [Finding Requirements, Tasks, and Tests](/getting-started/finding-requirements-tasks-and-tests) * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Console AI Search](/ai/console-ai-search) # Finding Requirements, Tasks, and Tests Locate work items using Global Search, project navigation, filters, and saved views. ### Overview Use this workflow to locate a specific item or build a clean list. The same patterns apply to Requirements, Tasks, and Tests. {% hint style="info" %} Screenshot placeholder: Global Search results showing Requirements, Tasks, and Tests grouped by type. {% endhint %} {% columns %} {% column %} **What is covered** * Find items by keyword or ID * Narrow results with scope and filters * Build repeatable views for daily review {% endcolumn %} {% column %} **At a glance** * **Time:** \~5 minutes * **Access:** Project viewer or higher {% endcolumn %} {% endcolumns %} ### Key Concepts * **Global Search**: cross-scope search for items * **Project navigation**: reliable browsing when Project is known * **Save View**: stored view configuration for repeatable lists ### How It’s Used Use Global Search to locate items by keyword or ID. Use Save Views for daily review lists. ### Benefits * Faster retrieval of single items * Repeatable lists for triage and review ### Setup Steps #### Method 1: Global Search (fastest) Global Search is best when item location is unknown. {% stepper %} {% step %} ### Open Global Search Press `Cmd + K` (macOS) or `Ctrl + K` (Windows/Linux). {% endstep %} {% step %} ### Search using known context Try: * a unique keyword from the title or description * an ID like `REQ-042` or `TASK-015` (if IDs are enabled) * a Teammate name to find assigned work {% endstep %} {% step %} ### Filter until it’s obvious Reduce noise with filters like: * **Type** (Requirements vs Tasks vs Tests) * **Project** * **Status** / **Assignee** {% hint style="info" %} GIF placeholder: broad query → filter Type → filter Project → open the exact item. {% endhint %} {% endstep %} {% step %} ### Confirm context Use breadcrumbs to confirm Organization and Project. {% endstep %} {% endstepper %} Deep dive: * [Using Global Search](/getting-started/using-global-search) #### Method 2: Browse inside a Project (most reliable) Use this method when the Project is known. {% hint style="info" %} Screenshot placeholder: project left navigation highlighting Requirements, Tasks, and Testing. {% endhint %} #### Find requirements 1. Open the Project. 2. Go to **Requirements**. 3. Filter by Status, Owner, Process, or Priority (depending on configured fields). {% hint style="info" %} Screenshot placeholder: requirements list with the filter panel open. {% endhint %} #### Find tasks 1. Open the Project. 2. Go to **Tasks**. 3. Filter by assignee, status, and due date. {% hint style="info" %} Screenshot placeholder: tasks list filtered to `Assignee = `. {% endhint %} #### Find tests 1. Open the Project. 2. Go to **Testing** or **Tests**. 3. Filter by phase, owner, and execution status. #### Method 3: Filters + Save View (repeatable lists) Use a Save View for work checked daily. {% stepper %} {% step %} ### Apply filters For example: `Assignee = ` + `Status != Complete`. {% endstep %} {% step %} ### Save the view Name it so it scans fast. For example: `Tasks — Open (Assignee = )`. {% endstep %} {% step %} ### Reuse and share (optional) Open the saved view next time. Share it with the team when shared views are enabled. {% endstep %} {% endstepper %} Related: * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Saved Views and Templates](/getting-started/save-views-and-templates) #### Method 4: Console search (natural language) Use Console to get an answer, not a list. For example: * `show blocked requirements in finance` * `what tasks are overdue this week` * `tests that failed in UAT` Related: * [Console AI Search](/ai/console-ai-search) * [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search) ### Best Practices * Use Save Views for repeatable reviews. * Start with a broad search. Narrow with filters. * Confirm Organization and Project context with breadcrumbs. #### Troubleshooting
Item is not found (expected to exist) Check these in order: 1. Clear filters. Then search again. 2. Confirm the correct Organization and Project are selected. 3. Try a shorter keyword. 4. Confirm permission exists to view the item.
Only one item type appears in results A **Type** filter is likely enabled. Clear the type filter. Then re-run the search.
### Summary Use Global Search for cross-scope discovery. Use Save Views for repeatable review lists. Related: * [Saved Views and Templates](/getting-started/save-views-and-templates) * [Search and Navigation](/getting-started/search-and-navigation) * [Bookmarking and Favorites](/getting-started/bookmarking-and-favorites) # Bookmarking and Favorites Reduce navigation time by favoriting Organizations and Projects and bookmarking repeatable routes. ### Overview Bookmarking and favorites reduce navigation overhead. They exist to make repeatable routes one click away. ### Key Concepts * **Favorite**: in-app marker that keeps frequently used items near the top * **Browser bookmark**: saved URL for fast entry into a specific page * **Route**: repeatable navigation path, such as Organization → Project → Save View * **Scope**: access boundaries still apply to favorites and bookmarks ### How It’s Used Use favorites for frequently accessed Organizations and Projects. Use bookmarks for stable routes, such as a weekly review Save View. ### Benefits * Faster switching between active delivery areas * Lower risk of working in the wrong scope * Cleaner weekly cadence through repeatable review routes ### Setup Steps #### Favorite Organizations and Projects (in-app) {% stepper %} {% step %} ### Open the list page Open **Organizations** or the Project list. {% endstep %} {% step %} ### Mark as favorite Select the **star** or **favorite** action next to the target item. Availability varies by Account configuration. {% endstep %} {% step %} ### Maintain the list Remove favorites when work closes. Keep the list short for scanning. {% endstep %} {% endstepper %} #### Bookmark repeatable routes (browser) {% stepper %} {% step %} ### Open the target page Open the page that should be saved. For example: a Save View used in a weekly review. {% endstep %} {% step %} ### Create the bookmark Use the browser bookmark shortcut: * macOS: `Cmd + D` * Windows/Linux: `Ctrl + D` {% endstep %} {% step %} ### Name the bookmark Use a stable naming pattern. For example: `Transform — Organizations`. {% endstep %} {% step %} ### Organize the bookmarks Create a `Transform` bookmark folder. Group bookmarks by Organization or cadence. {% endstep %} {% endstepper %} ### Best Practices * Prefer Save Views for repeatable “my work” lists. * Bookmark team review views rather than raw lists. * Standardize naming, such as `Transform — — Weekly review`. * Avoid bookmarking pages that change often, such as temporary search results. ### Summary Favorites and bookmarks reduce daily navigation overhead. Related: * [Using Global Search](/getting-started/using-global-search) * [Finding Requirements, Tasks, and Tests](/getting-started/finding-requirements-tasks-and-tests) * [Saved Views and Templates](/getting-started/save-views-and-templates) # Browser Compatibility Supported browsers and required settings (JavaScript, cookies, and permissions). ### Overview Transform requires a modern, supported web browser. Core features require JavaScript and cookies. Use this page when diagnosing login, rendering, or permission prompts. Use [System Requirements](/getting-started/system-requirements) for device and network recommendations. ### Key Concepts * **JavaScript**: required to render the app UI * **Cookies**: required for session and preference storage * **Site permissions**: microphone and notifications (optional, feature-dependent) * **Extensions**: may interfere with scripts, cookies, or network requests ### How It’s Used Use this checklist during rollout. Use it as the first step in browser-based troubleshooting. ### Benefits * Fewer “page won’t load” issues * More reliable sign-in sessions * Cleaner audio capture when Meeting Notetaker is enabled ### Setup Steps #### 1) Use a modern browser Use an evergreen browser on the latest stable version. Update the browser regularly. #### 2) Enable JavaScript Confirm JavaScript is enabled for the Transform domain. #### 3) Allow cookies Confirm cookies are allowed for the Transform domain. Avoid strict cookie-blocking modes for primary usage. #### 4) Allow pop-ups when required Allow pop-ups for the Transform domain when a workflow opens a new window. #### 5) Configure site permissions (feature-dependent) * **Microphone**: required for Meeting Notetaker capture * **Notifications**: optional for browser-level notifications #### 6) Isolate extension-related issues Test in a private browsing window to reduce extension impact. Disable extensions that block scripts or cookies when issues occur. ### Best Practices * Standardize on one browser configuration across a delivery team. * Avoid running heavy privacy or script-blocking extensions during delivery work. * Use a dedicated browser profile for delivery work when policy allows. ### Summary Browser compatibility depends on a modern browser, enabled JavaScript, allowed cookies, and correct site permissions. Isolate issues by testing without extensions and with a clean cache state. Related: * [System Requirements](/getting-started/system-requirements) * [Login Problems](/troubleshooting/login-problems) * [Getting Help](/troubleshooting/getting-help) # System Requirements Recommended device, network, and screen specs for running Transform smoothly. ### Overview Transform runs in a modern web browser. No local installation is required. Use this page to validate device and network readiness. Use [Browser Compatibility](/getting-started/browser-compatibility) for required browser settings. ### Key Concepts * **Browser-based UI**: performance depends on browser and device resources * **Bandwidth**: affects load time and synchronization * **Memory (RAM)**: affects performance with large lists and many open tabs * **Screen resolution**: affects usability of dense grid views * **Microphone permissions**: required for Meeting Notetaker capture (when used) ### How It’s Used Use this checklist before a rollout. Use it when troubleshooting slowness or rendering issues. ### Benefits * Fewer performance issues during heavy delivery periods * Faster load and sync for large Projects * More reliable meeting capture when Meeting Notetaker is enabled ### Setup Steps #### 1) Validate network * Minimum: **10 Mbps** sustained download speed * Recommended: **25 Mbps+** for large Projects and analytics usage Prefer wired connections for long sessions. Avoid unstable public networks for delivery work. #### 2) Validate device resources * Minimum memory: **4 GB RAM** * Recommended memory: **8 GB+ RAM** Close unused tabs during heavy list editing. Restart the browser after long sessions. #### 3) Validate screen * Minimum resolution: **1280 × 768** * Recommended resolution: **1920 × 1080+** Larger screens reduce horizontal scrolling in grid views. #### 4) Validate Meeting Notetaker prerequisites (when enabled) * Confirm microphone permission is allowed for the Transform domain. * Use a stable network during meeting capture. * Provide a meeting join URL when starting capture. ### Best Practices * Keep the browser updated to the latest stable release. * Limit concurrent heavy tabs during bulk editing. * Use hard refresh only after confirming browser cache issues. ### Summary System readiness depends on stable bandwidth, sufficient memory, and a modern browser. Use Browser Compatibility to confirm required browser settings. Related: * [Browser Compatibility](/getting-started/browser-compatibility) * [Setting Up Meeting Notetaker](/ai/setting-up-meeting-notetaker) * [Getting Help](/troubleshooting/getting-help) # Key Concepts and Terminology Glossary for Transform objects, work items, and common abbreviations. ### Overview This glossary standardizes Transform terminology across an Account. Consistent terminology improves reporting, search, and governance.
### Key Concepts #### Account, Organization, Project * **Account**: top-level container for all work * **Organization**: container for a client, department, or business unit * **Project**: delivery container for a single transformation initiative #### Blueprint, Process, System * **Blueprint**: reusable structure applied to new Projects * **Process**: business workflow, phase, or workstream tracked in a Blueprint * **System**: application or platform that supports a Process A System can be a business application, such as an ERP system or a CRM system. #### Segment Types and Segments * **Segment Type**: a business dimension, such as Region or Department * **Segment**: a value inside a Segment Type Segments and Segment Types are managed at the Organization level. Start here: [Segmentation](/blueprints/segmentation) #### Work items * **Requirement**: statement of scope that must be delivered and validated * **Task**: executable work that implements scope * **Test case**: validation steps linked to a Requirement * **Artifact**: supporting file or reference linked to work items ### How It’s Used Use this glossary when defining Blueprints and reporting fields. Use it when standardizing naming across multiple Projects. ### Benefits * Fewer reporting inconsistencies across Projects * Faster onboarding through shared vocabulary * Cleaner search results and less duplicated work ### Setup Steps 1. Adopt this page as the default glossary for an Account. 2. Standardize page titles, field labels, and view names to match this glossary. 3. Link related pages in onboarding documentation to reduce repeated explanations. ### Best Practices * Avoid abbreviations for Organization and Project names. * Prefer dropdown fields over free text for reporting fields. * Use the term **Save View** for a stored view configuration. * Treat Segments as Organization-scoped structure, not tags. ### Summary This glossary defines the core Transform terms used across Account, Organization, and Project scopes. Related: * [Start Here](/getting-started/start-here) * [What Is Transform](/getting-started/what-is-transform) * [Understanding the Interface](/getting-started/understanding-the-interface) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # What Is Transform Understand what Transform does and why it reduces rework during business transformation delivery. ### Overview Transform turns project context into structured work. That structure reduces rework and improves governance. Transform is designed for complex transformation delivery. It connects requirements, tasks, tests, and artifacts to maintain traceability. ### Key Concepts
* **Account**: top-level container * **Organization**: container for a client, department, or business unit * **Project**: delivery container for a single initiative * **Blueprint**: reusable structure applied to new Projects * **Artifact**: supporting file or reference for project context * **Console**: natural-language search across Transform data (if enabled) Start with [Key Concepts and Terminology](/getting-started/key-concepts-and-terminology). ### How It’s Used Transform is typically used in four loops: 1. Capture context from artifacts, meetings, and decisions. 2. Convert context into requirements that represent scope. 3. Deliver scope through tasks and validate through testing. 4. Review change history to support governance and auditability. ### Benefits * Less rework from lost context and inconsistent documentation * Clear traceability from requirements to delivery and validation * Faster onboarding for new teammates through linked project history * Stronger governance through recorded decisions and change history ### Setup Steps Follow the default setup path: * [Start Here](/getting-started/start-here) ### Best Practices * Link scope to delivery: requirements → tasks → tests. * Capture decisions in comments, not side channels. * Reuse Blueprints to standardize structure across Projects. * Keep naming consistent across Organizations and Projects. ### Summary Core pages: * [Start Here](/getting-started/start-here) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [Understanding the Interface](/getting-started/understanding-the-interface) # New to Transform Get oriented on scope and access, then complete the core onboarding steps. ### Overview Use this page for fast orientation. Use [Start Here](/getting-started/start-here) for the recommended setup path. ### Key Concepts #### Scope model Transform is organized by scope. * **Account**: top-level container for all work * **Organization**: container for a client, department, or business unit * **Project**: delivery container for a single transformation initiative #### Access model Access is granted at the same scopes. Roles control actions within a scope. * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) ### How It’s Used Use this guide during onboarding. Use it again when setting up a new Organization. ### Benefits * Faster navigation through consistent scope concepts * Fewer access mistakes during rollout * Cleaner setup for Organizations and Projects ### Setup Steps #### Transform Platform Map {% embed url="" %} #### First 10 minutes Complete the steps in order. {% stepper %} {% step %} ### Configure profile Set display name and core preferences. * [Profile Configuration](/getting-started/profile-configuration) {% endstep %} {% step %} ### Join or create a Project Request Project access from an admin, or create the first Project. * [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Add Teammates Invite Teammates at the lowest scope that works. * [Add Teammates](/organizations-and-projects/add-teammates) {% endstep %} {% endstepper %} ### Best Practices * Use Organization scope for access to multiple Projects. * Use Project scope for external collaborators. * Adopt a single vocabulary for Blueprint and Project naming. ### Summary Next workflows: * Build a Blueprint: [Tutorial: Set Up a First Blueprint](/getting-started/tutorial-set-up-a-first-blueprint) * Learn views: [Working with Views](/getting-started/working-with-views) * Generate requirements: [Requirements Generation](/transformations/requirements) # Create a Transform Login Create a Transform login, verify email (if required), and complete minimum profile setup. ### Overview Use this guide when signing in to Transform for the first time. The flow starts from an invite or signup link. ### Key Concepts * **Login**: email-based sign-in identity * **Verification**: optional email validation step * **SSO**: sign-in through a centralized identity provider (if enabled) ### How It’s Used Use this setup during onboarding. Use it again when provisioning an additional admin login. ### Benefits * Faster access to Organizations and Projects * Reduced sign-in issues from incomplete setup ### Setup Steps {% stepper %} {% step %} ### Create a login 1. Open the invite or signup link. 2. Enter a work email. 3. Set a password, if prompted.
{% endstep %} {% step %} ### Verify email (if prompted) 1. Open the verification email. 2. Select the verification link.
{% endstep %} {% step %} ### Sign in Sign in using one of these methods: * Email and password * SSO (if enabled for the Organization) {% hint style="info" %} Screenshot placeholder: sign-in screen showing both **Email** and **SSO** options (if applicable). {% endhint %} {% endstep %} {% step %} ### Complete the minimum profile 1. Confirm name and role. 2. Set language and theme preferences, if needed.
{% endstep %} {% endstepper %} ### Best Practices * Use a work email tied to the Organization identity policy. * Store recovery information according to Organization policy. #### Troubleshooting
Verification email is not received * Check spam and quarantine folders. * Confirm the correct email address was used. * Request invite resend from an Account Admin.
Sign-in fails Start with [Login Problems](/troubleshooting/login-problems).
### Summary Next steps: * [Account Setup](/getting-started/account-setup) * [Quick Start Guide](/getting-started/quick-start-guide) # Profile Configuration Update name, photo, and security preferences used across collaboration and audit history. ### Overview Profile settings define how a Teammate appears across Projects. Accurate profile details improve collaboration and auditability. ### Key Concepts * **Display name**: appears in assignments, comments, and mentions * **SSO**: identity managed by an external provider (if enabled) * **2FA**: second factor for sign-in security (if enabled) ### How It’s Used Use this setup during onboarding. Use it when updating role changes or security policy changes. ### Benefits * Faster recognition in people pickers and activity feeds * Cleaner audit history with stable identity details * Reduced sign-in risk when security settings are enabled ### Setup Steps {% stepper %} {% step %} ### Open Profile settings Open the avatar menu in the top navigation. Select **My Profile** (or **Profile**). {% hint style="info" %} Screenshot placeholder: avatar menu with **My Profile** highlighted. {% endhint %} {% endstep %} {% endstepper %} #### Update profile details #### Profile photo Add a photo to improve recognition in people pickers. {% hint style="info" %} GIF placeholder: click avatar → upload photo → crop → save. {% endhint %} 1. Select the current avatar. 2. Upload an image. 3. Crop if prompted. 4. Save changes. {% hint style="info" %} Square images work best. Aim for at least 200×200 pixels. {% endhint %} #### Display name Display name appears in assignments, comments, and activity feeds. 1. Update **First name** and **Last name**. 2. Save changes. {% hint style="info" %} Screenshot placeholder: name fields (First name / Last name) and **Save** button. {% endhint %} #### Job title / role (if available) Add a title to provide context for stakeholders. Examples include roles such as: * Implementation lead * Project manager * Business analyst #### Contact information (if available) Common fields: * **Email** (often used for login and notifications) * **Phone** (optional) {% hint style="warning" %} Some Accounts lock email and password changes behind SSO. If editing is disabled, contact an admin. {% endhint %} #### Password and security #### Change password (if enabled) Only applies for email-and-password sign-in. {% stepper %} {% step %} ### Open the Security section From **My Profile**, open **Security** (or **Password**). {% endstep %} {% step %} ### Set a new password Enter: * Current password * New password * Confirm new password {% endstep %} {% step %} ### Save Select **Update password** (or **Save**). {% hint style="info" %} Screenshot placeholder: password change form (current / new / confirm). {% endhint %} {% endstep %} {% endstepper %} {% hint style="info" %} Use 12+ characters. Use a password manager when allowed by policy. {% endhint %} #### Two-factor authentication (2FA) (if available) Enable 2FA when available to strengthen sign-in security. {% hint style="info" %} Screenshot placeholder: 2FA section with **Enable** button and backup codes step. {% endhint %} #### Notifications (quick link) Use this guide for the full set of options: * [Notification Settings](/collaboration-and-automation/notification-settings) {% hint style="info" %} Screenshot placeholder: notifications panel link-out from My Profile. {% endhint %} ### Best Practices * Use a stable display name for audit history. * Avoid adding sensitive information to public profile fields. * Use SSO-managed identity fields as the source of truth when enabled. #### Troubleshooting
My Profile option is not available * Refresh the page after signing in. * Confirm the correct Account scope is selected. * If still missing, ask an Account Admin to confirm access.
Email or password cannot be changed This is usually expected with SSO. Ask an Account Admin how identity is managed for the Account.
### Summary Profile Configuration sets identity and security preferences for a Teammate profile. It affects assignments, comments, and audit history across Projects. Related: * [Appearance Settings](/getting-started/appearance-settings) * [Language Preferences](/getting-started/language-preferences) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) # Appearance Settings Select Light or Dark theme (or system default) for readability and accessibility. ### Overview Appearance settings control the theme used in the UI. Themes improve readability across different lighting conditions. ### Key Concepts * **Theme**: Light or Dark UI palette * **System default**: follows the operating system theme (if enabled) ### How It’s Used Use these settings during onboarding. Use them before screen sharing or training sessions. ### Benefits * Reduced eye strain in low-light conditions * Improved readability during screen sharing * Consistent UI across devices (when supported) ### Setup Steps {% columns %} {% column %} **What can be changed** * Theme: **Light** or **Dark** * **System default** (if enabled) {% endcolumn %} {% column %} **Why it matters** * Reduce eye strain in low-light settings * Improve readability during screen sharing * Keep a consistent experience across devices {% endcolumn %} {% endcolumns %} {% hint style="info" %} Screenshot placeholder: **Appearance** settings panel with the theme selector. {% endhint %} #### Open appearance settings {% stepper %} {% step %} ### Open Settings Open the avatar menu in the top navigation. Select **Settings**. {% hint style="info" %} Screenshot placeholder: avatar menu with **Settings** highlighted. {% endhint %} {% endstep %} {% step %} ### Go to Appearance Open the **Appearance** tab. {% endstep %} {% endstepper %} #### Choose a theme Changes apply immediately. {% hint style="info" %} GIF placeholder: switching from **Light** → **Dark** and back. {% endhint %} #### Light mode Use Light mode in bright environments. * High contrast text on light backgrounds * Best for presentations and screen sharing {% hint style="info" %} Screenshot placeholder: main Transform UI in **Light** mode. {% endhint %} #### Dark mode Use Dark mode in low-light environments. * Lower glare on dark backgrounds * Often more comfortable for long sessions {% hint style="info" %} Screenshot placeholder: main Transform UI in **Dark** mode. {% endhint %} #### System default (if available) If enabled, **System default** follows the operating system theme. * Matches macOS/Windows light or dark mode * Switches automatically when the operating system switches {% hint style="info" %} Screenshot placeholder: theme dropdown showing **System default**. {% endhint %} ### Best Practices {% hint style="info" %} * Use **Light** theme when screen sharing in bright rooms. * Use **Dark** theme for long sessions in dim lighting. * If UI spacing appears incorrect, reset browser zoom to 100%. {% endhint %} #### Troubleshooting
Appearance tab is not available Some Accounts hide some user settings. Ask an Account Admin to confirm the feature is enabled for the Account.
Theme keeps switching unexpectedly **System default** may be enabled. Switch the theme to **Light** or **Dark** to lock it.
### Summary Appearance Settings control UI theme selection for a Teammate profile. Changes apply immediately and affect UI readability. Related: * [Profile Configuration](/getting-started/profile-configuration) * [Language Preferences](/getting-started/language-preferences) * [Notification Settings](/collaboration-and-automation/notification-settings) # Language Preferences Set the preferred UI language. Some formats may follow locale settings. ### Overview Language settings control the language used for UI labels and system text. These settings do not translate content entered by Teammates. ### Key Concepts * **UI language**: language for navigation, labels, and system messages * **Locale formatting**: date and number formats tied to language or region (if enabled) ### How It’s Used Use these settings during onboarding. Use them when working across multilingual teams. ### Benefits * Clearer UI labels for Teammates across regions * Reduced misinterpretation of system messages ### Setup Steps {% columns %} {% column %} **What changes** * Navigation labels and UI text * Button labels and tooltips * System messages and some notifications {% endcolumn %} {% column %} **What does not change** * Tasks, requirements, and comments Teammates created * Organization and Project names * Custom field names (admin-defined) {% endcolumn %} {% endcolumns %} {% hint style="info" %} Screenshot placeholder: **Language** settings panel with the language dropdown. {% endhint %} #### Open language settings {% stepper %} {% step %} ### Open Settings Open the avatar menu in the top navigation. Select **Settings**. {% hint style="info" %} Screenshot placeholder: avatar menu with **Settings** highlighted. {% endhint %} {% endstep %} {% step %} ### Go to Language Open the **Language** tab. {% endstep %} {% endstepper %} #### Change language {% stepper %} {% step %} ### Select a language Open the **Language** dropdown. Search or scroll to find the required language. {% endstep %} {% step %} ### Save (if prompted) Some Accounts apply changes instantly. Others require **Save**. {% endstep %} {% step %} ### Confirm the UI updates The interface may refresh after the change. {% hint style="info" %} GIF placeholder: choose a language → UI refreshes → menus update. {% endhint %} {% endstep %} {% endstepper %} #### Dates, numbers, and locale (if applicable) Some Accounts also adjust formatting based on language or locale. Examples include formats such as: * Date order: `MM/DD/YYYY` vs `DD/MM/YYYY` * Thousands separators: `1,000` vs `1.000` {% hint style="info" %} Screenshot placeholder: a date field shown in two locales (example only). {% endhint %} ### Best Practices * Set language per Teammate for local readability. * Standardize date interpretation for planning and reporting. * Standardize deliverable language per Project when needed. #### Troubleshooting
Language setting does not save 1. Try again and click **Save** if it appears. 2. Hard refresh the page. 3. Sign out, then sign back in.
The UI is partially in the wrong language This is usually a browser locale override or cached assets. 1. Confirm the setting is saved in Transform. 2. Hard refresh the page. 3. Check browser preferred languages.
### Summary Language Preferences control UI labels and system text. Teammate-entered content remains in the original language. Related: * [Profile Configuration](/getting-started/profile-configuration) * [Appearance Settings](/getting-started/appearance-settings) * [Notification Settings](/collaboration-and-automation/notification-settings) # Create a Project Create a Project using the setup form and wizard. {% columns %} {% column %} **What will be completed** * Create a new Project in Transform * Configure basic project settings * Use the project setup wizard * Open the Project dashboard {% endcolumn %} {% column %} **At a glance** * **Time:** \~5 minutes * **Access:** project creation permission\ See [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) {% endcolumn %} {% endcolumns %} ### Overview Projects are the delivery containers for transformation work. Projects hold requirements, tasks, tests, and artifacts. ### Key Concepts * **Organization**: container that holds Projects * **Project status**: lifecycle state for visibility and reporting * **Template Project**: optional starting configuration copied from a standard Project ### How It’s Used Create a Project at the start of an initiative. Use a Template Project when standard defaults are required. ### Benefits * Clean separation of work by initiative * Consistent reporting and governance within an Organization * Faster setup through templates (when enabled) ### Setup Steps #### 1) Open Project creation {% hint style="warning" %} If **New Project** is not available, Project creation access is missing. Review [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) or request access from an Admin. {% endhint %} {% columns %} {% column %} To start creating a Project: * Sign in to Transform * Navigate to the Organization * Click the **New Project** (or **Add Project**) button The Add Project form will open. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} #### 2) Enter Project information Provide basic details about the Project. {% columns %} {% column %} To add Project details: * Enter a **Project Name** (required) * Use a clear, descriptive name * For example: `{Organization} {initiative}` * Add a **Project Description** (optional) * Brief overview of the Project scope * Include key objectives or deliverables * Select a **Status** from the dropdown (defaults to **Not Started**) Tip: Include stable context such as an Organization name or initiative name. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} #### 3) Set Project timeline Define when the Project starts and ends. {% columns %} {% column %} To set Project dates: * Click the **Start Date** dropdown * Select when the Project begins * Click the **End Date** dropdown * Select the expected completion date Tip: Accurate dates improve capacity planning and reporting. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} #### 4) Select Template Project (optional) Copy a template to save setup time (if templates are available in the Organization). {% columns %} {% column %} To use a template: * Click the **Template Project** dropdown * Select a template (if available) What gets copied from templates: * Project structure and organization * Custom fields and settings * Standard workflows Leave this blank to start from scratch. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} #### 5) Create the Project Review entries and create the Project. * Review the entered information. * Click **Submit**. #### After creation After creation, the Project opens automatically. Expected results: * Project name in the header * Project status indicator * Empty work area ready for requirements and tasks * Left navigation for Project sections
### Best Practices * Establish naming conventions before creating many Projects. * Set start and end dates early for reporting consistency. * Use templates for repeatable governance patterns. #### Troubleshooting
New Project button is not available * Confirm Project creation permission exists in the Organization. * See [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * Request Project creation access from an Admin.
Project creation form cannot be submitted * Confirm **Project Name** is filled (required). * Confirm end date is after start date. * Confirm all required fields are complete.
Project details are incorrect after creation * Edit Project settings after creation. * Update name, dates, and other fields in Project details.
### Summary Next steps: * [Create and Assign Tasks](/transformations/create-and-assign-tasks) * [Add Teammates](/organizations-and-projects/add-teammates) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) Support: * [Contact Support](/resources/contact-support) # Understanding the Interface Get oriented on navigation, scope, and core UI patterns used for daily work. ### Overview This page covers navigation, scope, and core UI patterns. Transform is organized by scope: **Account → Organization → Project**. {% columns %} {% column %} **What is covered** * Scope and breadcrumbs * Moving between Organizations and Projects * Finding work with search and views {% endcolumn %} {% column %} **At a glance** * **Time:** \~5 minutes * **Access:** Any Teammate {% endcolumn %} {% endcolumns %} {% hint style="info" %} Screenshot placeholder: full Transform interface with callouts for breadcrumbs, global search, left nav, and view selector. {% endhint %} ### Key Concepts * **Scope**: current level in the Account → Organization → Project hierarchy * **Views**: different ways to see the same data (List, Board, Gantt) * **Detail panel**: side panel for reviewing and editing items ### How It’s Used Use this page during onboarding. Use it when diagnosing navigation or “wrong scope” issues. ### Benefits * Faster navigation and fewer context mistakes * Better adoption of views and filtering for daily work ### Setup Steps ### Quick orientation {% stepper %} {% step %} ### Confirm scope Most pages live at one of these levels: * **Account:** global configuration and admin * **Organization:** client or department container * **Project:** where requirements, tasks, tests, and artifacts live {% hint style="info" %} Screenshot placeholder: breadcrumbs or scope indicator showing current level (Account vs Organization vs Project). {% endhint %} {% endstep %} {% step %} ### Switch organizations and projects Use breadcrumbs and selectors to move between scopes. When in doubt, return to **Organizations** and open the correct Project again. {% hint style="info" %} GIF placeholder: switch Organization → switch Project → show breadcrumbs updating. {% endhint %} {% endstep %} {% step %} ### Use global search Use search when item location is unknown. * [Using Global Search](/getting-started/using-global-search)
{% endstep %} {% step %} ### Learn the left navigation The left nav changes based on scope. Expect different options at Account vs Organization vs Project level. {% hint style="info" %} Screenshot placeholder: side-by-side of left nav at Organization level vs Project level. {% endhint %} {% endstep %} {% step %} ### Use views + the detail panel Views control how the same data is displayed. Start with List, then try Board and Gantt. * [Working with Views](/getting-started/working-with-views) {% hint style="info" %} Screenshot placeholder: view selector showing List/Board/Gantt, plus filter/sort/group controls. {% endhint %} {% hint style="info" %} GIF placeholder: click an item in a list → detail panel opens on the right → edit a field → close panel. {% endhint %} {% endstep %} {% endstepper %} ### Main navigation {% columns %} {% column %} #### Left navigation Use the left panel to move between major areas. Common entries: * **Organizations / Projects** (depending on scope) * **Blueprints** * **Transformations / Work** * **Settings** (scope-specific) {% hint style="info" %} Screenshot placeholder: left navigation with key sections labeled. {% endhint %} {% endcolumn %} {% column %} #### Top bar Use the top bar for global actions. * **Search** (global) * **Notifications** * **Profile menu** (preferences, sign out) * **Help** {% hint style="info" %} Screenshot placeholder: top bar with Search, Notifications, Profile menu, and Help labeled. {% endhint %} {% endcolumn %} {% endcolumns %} ### Scope levels: account, organization, project #### Account level Account is the top-level container. Typical actions: * Create and manage organizations * Manage account-wide settings (admins) {% hint style="info" %} Screenshot placeholder: account home showing the Organizations list/grid. {% endhint %} #### Organization level Organizations usually map to a client, department, or business unit. Typical actions: * Create and manage projects * Manage Organization teammates (if enabled) {% hint style="info" %} Screenshot placeholder: organization page showing the Projects list and org header. {% endhint %} #### Project level Projects (transformations) are where day-to-day delivery happens. Typical actions: * Work on requirements, tasks, testing, and artifacts * Track status, activity, and decisions {% hint style="info" %} Screenshot placeholder: project home/dashboard showing left nav and a work list. {% endhint %} ### Key interface elements #### Views toolbar Use the toolbar to change the view configuration. Common controls: * **View selector** (List / Board / Gantt) * **Filter**, **Sort**, **Group** * **Columns** (show/hide fields) {% hint style="info" %} Screenshot placeholder: views toolbar with the main controls labeled. {% endhint %} Related: * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) #### Detail panel Click almost any row to open the detail panel. It keeps the list visible while reviewing and editing. {% hint style="info" %} Screenshot placeholder: list view on the left + open detail panel on the right. {% endhint %} #### Breadcrumbs Breadcrumbs keep context visible. Use breadcrumbs to jump back up the scope tree. {% hint style="info" %} Screenshot placeholder: breadcrumb trail showing Organization → Project → Section. {% endhint %} #### Activity and history Use activity signals to answer “what changed?” quickly. Related: * [Comments and History](/collaboration-and-automation/comments-and-history) ### Tips and shortcuts * Use **Cmd/Ctrl + K** for search (fastest navigation). * Use **Esc** to close panels and dialogs. * Use the browser **Back** button. * Create a Save View for repeatable review lists. Related: [Saved Views and Templates](/getting-started/save-views-and-templates) ### Best Practices * Use breadcrumbs to confirm Organization and Project context. * Use views for repeatable work lists and reviews. * Keep shared views stable and predictable. ### Summary Next steps: * Vocabulary: [Key Concepts and Terminology](/getting-started/key-concepts-and-terminology) * Search: [Using Global Search](/getting-started/using-global-search) * Views: [Working with Views](/getting-started/working-with-views) * Save Views: [Saved Views and Templates](/getting-started/save-views-and-templates) # Quick Start Guide Create an Organization and Project, then set navigation defaults for daily work. ### Overview Use this guide after sign-in is working. The outcome is a working Organization and Project. {% columns %} {% column %} **What is covered** * Create an Organization * Create a Project * Learn the core navigation patterns * Create a baseline Save View for repeatable reviews {% endcolumn %} {% column %} **At a glance** * **Time:** \~15–30 minutes * **Access:** Account Admin for Organization creation + Project creation permission {% endcolumn %} {% endcolumns %} {% hint style="info" %} Screenshot placeholder: account navigation with **Organizations** highlighted. {% endhint %} ### Key Concepts * **Organization**: container for a client, department, or business unit * **Project**: delivery container inside an Organization * **Save View**: stored view configuration for repeatable lists ### How It’s Used Use this guide during initial rollout. Use it for repeatable onboarding of additional Organizations. ### Benefits * Faster setup for the first Project * Cleaner navigation and fewer “lost in scope” issues ### Setup Steps #### Prerequisites * Sign-in is working. * An Organization name is available (client, department, or business unit). * A Project name is available. {% hint style="warning" %} If Organization or Project creation is not available, request access from an admin. {% endhint %} Follow the steps in order. {% stepper %} {% step %} ### Create an organization Organizations separate work by client, department, or business unit. * [Create an Organization](/organizations-and-projects/create-an-organization) {% hint style="info" %} Screenshot placeholder: Organizations list with **New organization** highlighted. {% endhint %} {% endstep %} {% step %} ### Create a Project Create a Project inside the new Organization. * [Create a Project](/getting-started/create-a-project) {% hint style="info" %} Screenshot placeholder: organization header with **New project** (or **Add project**) action highlighted. {% endhint %} {% endstep %} {% step %} ### Learn the interface basics Get oriented on navigation, scope, and search. * [Understanding the Interface](/getting-started/understanding-the-interface) {% hint style="info" %} GIF placeholder: switch organization → project and point out breadcrumbs + global search. {% endhint %} {% endstep %} {% step %} ### Create a baseline Save View Save Views reduce rework during weekly reviews. 1. Navigate to **Tasks** or **Requirements** in the Project. 2. Apply a minimal filter set, such as `Status != Complete`. 3. Select **Save view** (or equivalent action). 4. Name the view with intent, such as `Team — Weekly review`. {% hint style="info" %} GIF placeholder: create a filtered list, then save it as a team view. {% endhint %} {% endstep %} {% endstepper %} ### Best Practices * Create a small first Project and iterate. * Establish a naming pattern before creating many Projects. * Confirm access scope before inviting external stakeholders. ### Summary Common next workflows: * Add Teammates: [Add Teammates](/organizations-and-projects/add-teammates) * Understand access scope: [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * Build structure before scaling: [Blueprint Fundamentals](/blueprints/blueprint-fundamentals) * Customize how you work: [Working with Views](/getting-started/working-with-views) * Start capturing requirements: [Requirements Generation](/transformations/requirements) * Hands-on walkthroughs: [First Steps Tutorials](/getting-started/first-steps-tutorials) Support routing: {% hint style="info" %} * Sign-in support: [Login Problems](/troubleshooting/login-problems) * Troubleshooting: [Getting Help](/troubleshooting/getting-help) * Support request: [Contact Support](/resources/contact-support) {% endhint %} # Account Setup Create a login, configure profile details, and set language and appearance preferences. ### Overview Use this page as the default path for setting up a new login and profile. This setup supports clean onboarding and collaboration. {% columns %} {% column %} **What is covered** * Create or activate an account login * Configure profile details * Set appearance and language preferences * Review access scope before inviting Teammates {% endcolumn %} {% column %} **At a glance** * **Time:** \~15–45 minutes * **Access:** Any Teammate (some actions require admin rights) {% endcolumn %} {% endcolumns %}
### Key Concepts * **Account**: top-level container for Organizations and Projects * **Teammate**: person record with access at one or more scopes * **Profile settings**: personal preferences and identity settings ### How It’s Used Use this setup during initial rollout. Use it again when onboarding new Teammates. ### Benefits * Faster onboarding and fewer access issues * More consistent identity and notification behavior * Cleaner collaboration through correct profile details ### Setup Steps Complete the steps in order. {% stepper %} {% step %} ### Create a Transform login Complete this step when signing in for the first time. * [Create a Transform Login](/getting-started/create-a-transform-login) {% endstep %} {% step %} ### Run the quick start Create the first Organization and Project. * [Quick Start Guide](/getting-started/quick-start-guide) {% endstep %} {% step %} ### Configure profile Add identity details so Teammates can recognize the profile. * [Profile Configuration](/getting-started/profile-configuration) {% endstep %} {% step %} ### Set appearance Pick a theme for readability and accessibility. * [Appearance Settings](/getting-started/appearance-settings) {% endstep %} {% step %} ### Set language Set the interface language. * [Language Preferences](/getting-started/language-preferences) {% endstep %} {% step %} ### Understand access levels (before inviting people) Access levels control what Teammates can see and edit. * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) {% endstep %} {% endstepper %} ### Best Practices * Configure profile details before adding many Teammates. * Review access levels before inviting external stakeholders. * Keep notification settings lean to reduce noise. ### Summary Common next steps: * Add Teammates: [Add Teammates](/organizations-and-projects/add-teammates) * Create an Organization: [Create an Organization](/organizations-and-projects/create-an-organization) * Create a Project: [Create a Project](/getting-started/create-a-project) * Learn the vocabulary: [Key Concepts and Terminology](/getting-started/key-concepts-and-terminology) * Follow hands-on walkthroughs: [First Steps Tutorials](/getting-started/first-steps-tutorials) Support routing: {% hint style="info" %} * Sign-in issues: [Login Problems](/troubleshooting/login-problems) * Troubleshooting: [Getting Help](/troubleshooting/getting-help) * Support: [Contact Support](/resources/contact-support) {% endhint %} # Tutorial: Creating an Organization and Project ### Overview Organizations separate work by client, department, or business unit. Projects contain delivery work for one transformation initiative. ### Key Concepts * **Organization**: top-level client or department container * **Project**: delivery container inside an Organization * **Scope**: current Account → Organization → Project context ### How It’s Used Use this tutorial during initial rollout. Use this tutorial when onboarding a new Organization. ### Benefits * Clear separation of work across organizations * Cleaner access control by scope * Faster navigation with fewer “wrong project” edits ### Setup Steps {% stepper %} {% step %} ### Create an Organization 1. Navigate to **Organizations**. 2. Select **New organization**. 3. Enter an Organization name. 4. Select **Create**. Related: [Create an Organization](/organizations-and-projects/create-an-organization) {% endstep %} {% step %} ### Create a Project 1. Open the Organization. 2. Select **New project** (or **Add project**). 3. Enter a Project name. 4. Select **Create**. Related: [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Confirm scope and navigation 1. Open the Project. 2. Confirm breadcrumbs show the correct Organization and Project. 3. Use left navigation to open **Requirements** and **Tasks**. Related: [Understanding the Interface](/getting-started/understanding-the-interface) {% endstep %} {% endstepper %} ### Best Practices * Use one Organization per client or department. * Establish a Project naming convention early. * Invite Teammates at the lowest scope that works. ### Summary Next actions: * [Add Teammates](/organizations-and-projects/add-teammates) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [Blueprint Fundamentals](/blueprints/blueprint-fundamentals) # Tutorial: Set Up a First Blueprint ### Overview Blueprints define reusable structure for new Projects. Blueprints reduce setup time and standardize governance. ### Key Concepts * **Blueprint**: reusable configuration for new Projects * **Processes**: reusable process map used for navigation and reporting * **Systems**: reusable application inventory linked to processes * **Segmentation**: Segment Types and Segments used for scoping and reporting {% hint style="info" %} Segment Types and Segments are scoped to the Organization level. {% endhint %} ### How It’s Used Use a Blueprint before creating many Projects. Use one Blueprint per line of business when delivery patterns differ. ### Benefits * Standard structure across Projects * Faster onboarding for delivery teams * Cleaner reporting and traceability ### Setup Steps {% stepper %} {% step %} ### Create the Blueprint 1. Navigate to **Blueprints**. 2. Select **New blueprint**. 3. Enter a name aligned to the line of business. 4. Select **Create**. Related: [Creating Blueprints](/blueprints/creating-blueprints) {% endstep %} {% step %} ### Define Processes 1. Open **Processes** in the Blueprint. 2. Add a small process set, such as 10–30 entries. 3. Add parent processes when rollups are needed. Related: [Processes](/blueprints/creating-blueprints/processes)\ Related: [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) {% endstep %} {% step %} ### Define Systems and System Types 1. Open **Systems** in the Blueprint. 2. Create System Types for consistent classification. 3. Add Systems and link Systems to Processes. Related: [Create Systems](/blueprints/systems-management/create-systems)\ Related: [System Types](/blueprints/systems-management/system-types) {% endstep %} {% step %} ### Define Segmentation (optional) 1. Open **Segmentation**. 2. Define Segment Types aligned to reporting needs. 3. Add Segments for the Organization structure. Related: [Segmentation](/blueprints/segmentation) {% endstep %} {% endstepper %} ### Best Practices * Start small. Expand after teams start delivering work. * Standardize naming for Processes and Systems. * Keep Segment Types stable to protect reporting continuity. ### Summary Next action: * Create a Project from the Blueprint: [Create a Project](/getting-started/create-a-project) # Tutorial: Creating a First Transformation ### Overview Transformations are delivered through requirements, tasks, and tests. This tutorial creates a small, end-to-end delivery loop in one Project. ### Key Concepts * **Requirement**: reviewable scope statement * **Task**: owned execution work tied to scope * **Test case**: verification step tied to requirements * **Traceability**: links across requirements, tasks, and tests ### How It’s Used Use this tutorial after the first Project is created. Use this tutorial to align delivery teams on a standard flow. ### Benefits * Faster conversion from discovery to execution * Clear ownership and progress signals * Measurable coverage through linked tests ### Setup Steps {% stepper %} {% step %} ### Create 3–5 requirements 1. Navigate to **Requirements**. 2. Select **Create**. 3. Enter a requirement statement and acceptance criteria. 4. Set an initial status, such as **Draft**. Related: [Requirements](/transformations/requirements) {% endstep %} {% step %} ### Create tasks linked to requirements 1. Open one requirement. 2. Select **Create task** (or equivalent action). 3. Assign one Teammate as owner. 4. Set a due date when scheduling is needed. Related: [Create and Assign Tasks](/transformations/create-and-assign-tasks) {% endstep %} {% step %} ### Create test cases for coverage 1. Navigate to **Testing**. 2. Select **Create test case**. 3. Link the test case to the relevant requirement. 4. Set status to **Draft** or **Ready** based on readiness. Related: [Create Test Cases](/transformations/create-test-cases)\ Related: [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) {% endstep %} {% step %} ### Review progress in a view 1. Open **Tasks**. 2. Filter for open work. 3. Save the configuration as a Save View. Related: [Working with Views](/getting-started/working-with-views) {% endstep %} {% endstepper %} ### Best Practices * Keep one owner per task. * Use statuses to signal intent, not optimism. * Link tests early to protect coverage reporting. ### Summary The Project now contains linked requirements, tasks, and tests. Next action: * Add dependency signals: [Dependencies and Relationships](/transformations/dependencies-and-relationships) # Tutorial: Working with Views (List, Board, Gantt) Create a view, switch between List/Board/Gantt, and save configurations teams can reuse. ### Overview Views shape how lists and boards are reviewed. This tutorial creates one view, then switches view types. ### Key Concepts * **View type**: List, Board, or Gantt presentation * **Save View**: stored configuration for reuse * **Visibility**: private or shared view access ### How It’s Used Use this tutorial when starting a new Project. Use it again when standardizing weekly review views. ### Benefits * Faster reviews with repeatable layouts * Cleaner governance through shared views * Less rework caused by inconsistent filters and columns ### Setup Steps {% stepper %} {% step %} ### Open the view selector 1. Open the Project. 2. Navigate to an area with views, such as **Tasks**. 3. Select the current view name. {% hint style="info" %} Screenshot placeholder: view selector dropdown showing existing views. {% endhint %} {% endstep %} {% step %} ### Create a new view 1. Select **New view**. 2. Enter a view name aligned to intent. 3. Select **Create**. {% hint style="info" %} Screenshot placeholder: new view dialog with name field. {% endhint %} {% endstep %} {% step %} ### Choose a view type Select a view type based on the workflow. {% tabs %} {% tab title="List" %} Use List for scanning and editing fields quickly. Next: [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) {% endtab %} {% tab title="Board" %} Use Board for status-based workflow and drag-and-drop updates. Next: [Creating and Customizing Board Views](/getting-started/creating-and-customizing-board-views) {% endtab %} {% tab title="Gantt" %} Use Gantt for timeline planning and dependency visibility. Next: [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Customize filters and layout 1. Add one filter, such as `Status != Complete`. 2. Adjust one layout setting, such as columns or grouping. 3. Confirm the list reflects the intent. {% hint style="info" %} GIF placeholder: apply a filter, then reorder columns, then clear the filter. {% endhint %} {% endstep %} {% step %} ### Save and share 1. Select **Save view** (or **Save as**). 2. Set visibility to **Team** for shared standards. 3. Keep personal variations as **Private**. {% hint style="info" %} Screenshot placeholder: visibility options in the view share modal. {% endhint %} {% endstep %} {% endstepper %} ### Best Practices * Keep shared views minimal and stable. * Duplicate a view before major changes. * Use consistent prefixes, such as `Team —` and `Me —`. ### Summary Next actions: * [Saved Views and Templates](/getting-started/save-views-and-templates) * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) # Tutorial: Using Meeting Notetaker and Console ### Overview Meeting Notetaker captures meetings into searchable notes. Console queries Project content to surface decisions and next steps. ### Key Concepts * **Meeting Notetaker**: capture and summary pipeline for meetings * **Meeting summary**: structured output used for follow-ups * **Console**: natural language search across Project content ### How It’s Used Use this tutorial during discovery and weekly governance. Use it to turn meeting outcomes into requirements and tasks. ### Benefits * Faster capture of decisions and action items * Cleaner traceability from meetings to requirements * Less time spent re-reading threads and notes ### Setup Steps {% stepper %} {% step %} ### Set up Meeting Notetaker 1. Confirm Meeting Notetaker is enabled for the Account. 2. Configure capture settings and permissions. Related: [Setting Up Meeting Notetaker](/ai/setting-up-meeting-notetaker) {% endstep %} {% step %} ### Capture a meeting Capture one meeting to generate searchable content. Related: [Capturing Meetings Automatically](/ai/capturing-meetings-automatically) {% endstep %} {% step %} ### Review the summary Review summary output for correctness. Related: [Reviewing Meeting Summaries](/ai/reviewing-meeting-summaries) {% endstep %} {% step %} ### Convert key notes into requirements (optional) Convert meeting notes into draft requirements when scope is discussed. Related: [Converting Meeting Notes to Requirements](/ai/converting-meeting-notes-to-requirements) {% endstep %} {% step %} ### Query outcomes in Console Run queries such as: * `decisions made last week` * `blocked items` * `approved requirements` Related: [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search)\ Related: [Finding Decisions and Approvals](/ai/finding-decisions-and-approvals) {% endstep %} {% endstepper %} ### Troubleshooting
I don’t see Meeting Notetaker This is usually a permissions or plan issue. Ask an Account Admin to confirm Meeting Notetaker is enabled.
### Best Practices * Capture governance meetings consistently. * Convert action items into tasks within 24 hours. * Keep requirement statements in the requirement record, not only notes. ### Summary Next actions: * [Managing Meeting History](/ai/managing-meeting-history) * [Console Search Tips and Examples](/ai/console-search-tips-and-examples)
Console results are empty Common causes: * No data exists in the project yet (capture a meeting first). * Project permissions do not allow access to the indexed content.
# Tutorial: Using Analytics Dashboards ### Overview Dashboards summarize delivery signals into a single view. This tutorial opens one dashboard and applies filters for review. ### Key Concepts * **Dashboard**: curated set of widgets for a reporting purpose * **Widget**: chart or metric backed by Project data * **Filter**: constraint applied to focus a review ### How It’s Used Use dashboards during weekly governance. Use dashboards to align stakeholders on progress and risk. ### Benefits * Faster status reviews * Consistent reporting across Projects * Earlier visibility into slippage and blockers ### Setup Steps {% stepper %} {% step %} ### Open Analytics 1. Navigate to **Analytics**. 2. Select **Dashboards**. {% endstep %} {% step %} ### Select a dashboard 1. Open a dashboard aligned to the review purpose. 2. Confirm the dashboard scope matches the intended Project. {% endstep %} {% step %} ### Apply filters 1. Apply one filter at a time. 2. Validate widget updates after each filter change. 3. Clear filters after the review. {% endstep %} {% step %} ### Share the output (optional) 1. Capture a link or export when supported. 2. Include filter context in the summary message. {% endstep %} {% endstepper %} ### Best Practices * Review one dashboard consistently for trend comparability. * Keep filters consistent across reporting cycles. * Pair dashboard review with a saved work list for follow-up. ### Summary Related: * [Getting Started with Analytics](/analytics/getting-started-with-analytics) * [Dashboards](/analytics/dashboards) # First Steps Tutorials ### Overview Use these tutorials during initial rollout. Each tutorial produces a concrete output in an Organization or Project. ### Key Concepts * **Tutorial**: guided sequence with a specific outcome * **Checkpoint**: expected state after a step * **Repeatable setup**: patterns that can be reused across Projects ### How It’s Used Run one tutorial per session. Use a small pilot Project for the first pass. ### Benefits * Faster onboarding for delivery teams * Cleaner setup with fewer rework loops * Shared language for scope, work items, and reporting ### Setup Steps Select a tutorial based on the immediate goal. * [Tutorial: Creating an Organization and Project](/getting-started/tutorial-creating-an-organization-and-project) * [Tutorial: Set Up a First Blueprint](/getting-started/tutorial-set-up-a-first-blueprint) * [Tutorial: Creating a First Transformation](/getting-started/tutorial-creating-a-first-transformation) * [Tutorial: Working with Views (List, Board, Gantt)](/getting-started/tutorial-working-with-views-list-board-gantt) * [Tutorial: Using Meeting Notetaker and Console](/getting-started/tutorial-using-meeting-notetaker-and-console) * [Tutorial: Using Analytics Dashboards](/getting-started/tutorial-using-analytics-dashboards) ### Best Practices * Standardize naming before creating many Projects. * Keep one baseline Blueprint per line of business. * Create Save Views early for weekly reviews. ### Summary Use tutorials to establish repeatable structure. Then expand into role-specific workflows, such as requirements, tasks, and testing. # Start Here Follow a recommended setup path for initial Account, Organization, Project, and Teammate setup. ### Overview Use this page as the default onboarding path for a new Account. Follow the setup steps in order. ### Key Concepts #### Account, Organization, Project Transform is organized by scope. * **Account**: top-level container for all work * **Organization**: container for a client, department, or business unit * **Project**: delivery container for a single transformation initiative #### Teammates Teammates are people records with roles at one or more scopes. Access should follow least privilege. #### Blueprints Blueprints define reusable structure for new Projects. Blueprints reduce setup work and standardize governance. ### How It’s Used Use this path during initial rollout. Use it again when onboarding a new Organization. ### Benefits * Faster setup for new Organizations and Projects * Consistent structure across initiatives * Cleaner access control and auditability ### Setup Steps {% stepper %} {% step %} ### Create a Transform login Create a login when signing in for the first time. * [Create a Transform Login](/getting-started/create-a-transform-login) {% endstep %} {% step %} ### Create an organization Create one Organization per client or department. * [Create an Organization](/organizations-and-projects/create-an-organization) {% endstep %} {% step %} ### Invite teammates Invite Teammates at the lowest scope that works. * [Add Teammates](/organizations-and-projects/add-teammates) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) {% endstep %} {% step %} ### Build the first Blueprint Start with a template. Customize after teams start using it. * [Tutorial: Set Up a First Blueprint](/getting-started/tutorial-set-up-a-first-blueprint) {% endstep %} {% step %} ### Create the first Project Create a Project from a Blueprint. * [Create a Project](/getting-started/create-a-project) {% endstep %} {% endstepper %} ### Best Practices * Create Organizations early to simplify access control. * Standardize naming for Organizations and Projects. * Keep Account Admin access limited. * Establish a Blueprint before creating many Projects. ### Summary Recommended reading: * [New to Transform](/getting-started/new-to-transform) * [What Is Transform](/getting-started/what-is-transform) * [Understanding the Interface](/getting-started/understanding-the-interface) Next actions: * [Create an Organization](/organizations-and-projects/create-an-organization) * [Create a Project](/getting-started/create-a-project) * [Add Teammates](/organizations-and-projects/add-teammates) # Creating and Customizing List Views Create List Views and tailor columns, filters, sorting, grouping, and sharing for repeatable reviews. {% columns %} {% column %} **What is covered** * Create a List View * Pick and reorder columns * Filter, sort, and group rows * Save and share Save Views * Manage views over time {% endcolumn %} {% column %} **At a glance** * **Time:** \~5–10 minutes * **Access:** Project access with view permissions * **Prerequisites:** a Project with items to display {% endcolumn %} {% endcolumns %} ### Overview List Views show Project items in a table. Each view saves its own configuration. {% hint style="info" %} Screenshot placeholder: a populated List View table.\ Show rows, columns, and the view name. {% endhint %} ### Key Concepts * **Columns**: fields shown in the grid * **Filters**: rules that narrow the dataset * **Sorting**: review order inside the dataset * **Grouping**: collapsible sections based on a field * **Save View**: stored configuration for repeatable lists ### How It’s Used Use List Views for dense review and bulk editing. Use Save Views for repeatable triage and review. ### Benefits * Faster review through stable columns and filters * Cleaner reporting through consistent configurations ### Setup Steps #### 1) Create a new List View Open the Project. Open the view selector at the top. Choose **New view**. {% hint style="info" %} Screenshot placeholder: view selector dropdown.\ Highlight the **New view** action. {% endhint %} {% stepper %} {% step %} #### Name the view Use a short, scannable name. {% endstep %} {% step %} #### Choose type Select **List** as the view type. {% endstep %} {% step %} #### Create Confirm to create the view. {% endstep %} {% endstepper %} {% hint style="info" %} GIF placeholder: view selector → New view → name → List → Create.\ Keep it under 10 seconds. {% endhint %} #### 2) Customize columns Columns control what can be scanned and sorted. {% stepper %} {% step %} #### Open column settings Click **Customize** in the toolbar. Or click the **+** in the header row. {% endstep %} {% step %} #### Add or remove fields Toggle fields on or off. Start with **Assignee**, **Status**, and **Due date**. {% endstep %} {% step %} #### Reorder columns Drag headers left or right. {% endstep %} {% endstepper %} {% hint style="info" %} Screenshot placeholder: column picker panel.\ Show several fields enabled. {% endhint %} {% hint style="info" %} GIF placeholder: add a column → reorder → remove a column. {% endhint %} #### 3) Filter rows Filters narrow the rows in this view. {% stepper %} {% step %} #### Open filters Click **Filter** in the toolbar. {% endstep %} {% step %} #### Add a filter Click **Add filter**. Select a field and a condition. {% endstep %} {% step %} #### Combine filters Add more filters for a tighter view. {% endstep %} {% endstepper %} Common filters: * **Assignee** = `` * **Status** = `In progress` * **Due date** = `This week` * **Priority** = `High` {% hint style="info" %} Screenshot placeholder: filter builder with 2–3 filters.\ Redact sensitive names. {% endhint %} {% hint style="info" %} GIF placeholder: add a Status filter, then add an Assignee filter. {% endhint %} #### 4) Sort rows Click a column header to sort. Click again to reverse the order. {% hint style="info" %} Screenshot placeholder: header with a sort indicator and updated row order. {% endhint %} #### 5) Group rows (optional) Grouping creates collapsible sections. It helps with status reviews and ownership views. {% stepper %} {% step %} #### Turn on grouping Click **Group** in the toolbar. {% endstep %} {% step %} #### Choose a field Pick **Status**, **Assignee**, or **Priority**. {% endstep %} {% step %} #### Move items between groups Dragging an item updates the grouped field. {% endstep %} {% endstepper %} {% hint style="info" %} Screenshot placeholder: view grouped by Status with 3+ groups. {% endhint %} {% hint style="info" %} GIF placeholder: group by Status, then move one item. {% endhint %} #### 6) Save, share, and manage views Most changes save automatically. Some Accounts also support **Save as new view**. Sharing usually includes: * **Private** for personal views * **Team** for shared views {% hint style="info" %} Screenshot placeholder: view visibility options or sharing modal. {% endhint %} Open the view selector to manage views. Use **Rename**, **Duplicate**, or **Delete**. {% hint style="warning" %} Deleting a view is usually permanent. Duplicate first to keep a backup. {% endhint %} {% hint style="info" %} Screenshot placeholder: view menu with Rename, Duplicate, Delete. {% endhint %} ### Best Practices * Keep shared views stable and predictable. * Create personal views for daily triage. * Group by **Status** for standups. * Keep columns limited to what is used. Use consistent names, such as: * `Team — Weekly review` * `Tasks — This week` * `Tasks — Open (Assignee = )` #### Troubleshooting
New view option is not available This is usually a permissions issue. Confirm edit access exists in the Project. Ask a Project admin to grant access.
Teammates can’t see a view Check the view visibility. Change it from **Private** to **Team**, if available.
Filter or grouping didn’t save Confirm edits were applied to the correct view. Some teams lock shared views. Duplicate the view and edit the copy.
### Summary Expected outcome: * Confirm selected columns are visible. * Confirm filters and sorting are applied. * Confirm the view appears in the view selector. {% hint style="info" %} Screenshot placeholder: final view with columns, filters, and toolbar visible. {% endhint %} Related: * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Save Views and Templates](/getting-started/save-views-and-templates) * [Exporting Data from Views](/getting-started/exporting-data-from-views) # Creating and Customizing Board Views Use Board Views to manage work in lanes, drag items between statuses, and reuse shared configurations. {% columns %} {% column %} **What is covered** * Create a Board View * Choose lane (group-by) settings * Apply filters and sorting * Save and share a Save View {% endcolumn %} {% column %} **At a glance** * **Time:** \~5–10 minutes * **Access:** Project access with view permissions * **Prerequisites:** a Project with items and at least one status field {% endcolumn %} {% endcolumns %} ### Overview Board Views organize work into lanes. They work best for workflow and status-driven reviews. {% hint style="info" %} Screenshot placeholder: Board View with 3+ lanes and several cards. {% endhint %} ### Key Concepts * **Lane field**: field used to group cards into lanes * **Card order**: ordering inside a lane (sorting) * **Save View**: stored configuration for repeatable boards ### How It’s Used Use Board Views for standups and workflow reviews. Use lane fields such as Status or Assignee for ownership clarity. ### Benefits * Faster workflow review through visual lanes * Clear ownership through grouped lanes ### Setup Steps #### 1) Create a new Board View Open the view selector. Choose **New view**. Select **Board**. {% hint style="info" %} Screenshot placeholder: new view dialog with Board selected. {% endhint %} {% hint style="info" %} GIF placeholder: create a Board View from the view selector. {% endhint %} #### 2) Configure lanes Pick a lane field. Common lane fields are **Status**, **Assignee**, or **Priority**. {% hint style="info" %} Screenshot placeholder: lane (group-by) settings panel. {% endhint %} #### 3) Drag items between lanes Drag a card to another lane. This updates the lane field. {% hint style="info" %} GIF placeholder: drag a card to a different lane and show the field update. {% endhint %} #### 4) Filter and sort Use filters to focus the board. Use sorting to control card order. {% hint style="info" %} Screenshot placeholder: filters applied to a Board View. {% endhint %} #### 5) Save and share Most changes save automatically. Set visibility to **Private** or **Team**, if available. {% hint style="info" %} Screenshot placeholder: view visibility options in the share modal. {% endhint %} ### Best Practices * Keep shared boards stable and predictable. * Standardize lane fields for comparable reporting. * Use filters to create focused review boards. ### Summary Board Views group work into lanes for workflow reviews. Save Views store the configuration for repeatable use. Related: * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Save Views and Templates](/getting-started/save-views-and-templates) # Creating and Customizing Gantt Charts Use Gantt Charts to plan timelines, adjust dates, and visualize work across a schedule. {% columns %} {% column %} **What is covered** * Create a Gantt view * Set the date fields used on the timeline * Adjust timeline scale and range * Save and share a Save View {% endcolumn %} {% column %} **At a glance** * **Time:** \~5–15 minutes * **Access:** Project access with view permissions * **Prerequisites:** items with start/end dates (or due dates) {% endcolumn %} {% endcolumns %} ### Overview Gantt views show work across time. They work best for planning and sequencing. {% hint style="info" %} Screenshot placeholder: Gantt view showing a timeline with several bars. {% endhint %} ### Key Concepts * **Date mapping**: mapping view timeline to start/end fields * **Timeline scale**: zoom level and date range * **Save View**: stored configuration for repeatable timelines ### How It’s Used Use Gantt views for sequencing and dependency review. Use them for milestone planning and schedule alignment. ### Benefits * Clear timeline visibility across work items * Faster schedule change review through visual bars ### Setup Steps #### 1) Create a new Gantt view Open the view selector. Choose **New view**. Select **Gantt**. {% hint style="info" %} Screenshot placeholder: new view dialog with Gantt selected. {% endhint %} #### 2) Configure date fields Choose which fields map to: * Start date * End date (or duration) {% hint style="info" %} Screenshot placeholder: Gantt settings panel for start/end date mapping. {% endhint %} #### 3) Adjust the timeline Zoom in or out. Change the visible date range. {% hint style="info" %} GIF placeholder: zoom the Gantt timeline and pan to a new date range. {% endhint %} #### 4) Update dates Drag bar edges to change dates. Confirm the item date fields update. {% hint style="info" %} GIF placeholder: drag a bar to change dates and show the updated fields. {% endhint %} #### 5) Save and share Most changes save automatically. Set visibility to **Private** or **Team**, if available. {% hint style="info" %} Screenshot placeholder: view visibility options in the share modal. {% endhint %} ### Best Practices * Confirm date fields are standardized across items before relying on timelines. * Use Gantt views for schedule review, then validate details in List views. ### Summary Gantt views visualize work across a schedule. Save Views store the configuration for repeatable timeline reviews. Related: * [Save Views and Templates](/getting-started/save-views-and-templates) * [Exporting Data from Views](/getting-started/exporting-data-from-views) # Filtering and Sorting Data Filter rows and sort results to focus reviews and standardize repeatable lists. ### Overview Filters narrow a view to a relevant dataset. Sorting controls review order inside the dataset. Filters and sorting are typically stored with the current view configuration. {% hint style="info" %} Screenshot placeholder: List View toolbar with Filter and Sort controls highlighted. {% endhint %} ### Key Concepts * **Filter**: rule that includes or excludes rows * **Sort**: ordering rule for rows * **Save View**: stored configuration for repeatable filtering and sorting ### How It’s Used Use filters to build repeatable review lists. Use sorting to establish a stable review order. ### Benefits * Cleaner daily review lists * More consistent triage and reporting ### Setup Steps #### Filter rows Filters narrow the dataset shown in the view. {% stepper %} {% step %} #### Open filters Click **Filter** in the view toolbar. {% endstep %} {% step %} #### Add a filter Click **Add filter**. Choose a field and a condition. {% endstep %} {% step %} #### Combine filters Add multiple filters for a tighter view. {% endstep %} {% endstepper %} {% hint style="info" %} Screenshot placeholder: filter builder showing 2–3 filters and the filtered table results. {% endhint %} {% hint style="info" %} GIF placeholder: add a Status filter, then add an Assignee filter, then clear one filter. {% endhint %} {% hint style="success" %} **Best practices** * Start broad. Add one filter at a time. * Prefer Save Views for repeatable lists. * Name views by intent, such as `Team — Open items`. * Use sorting to answer one question, such as: “What’s due next?” * Keep shared views stable. Make variations as copies. {% endhint %} #### Sort rows Sorting changes row order. It does not change the underlying data. * Click a column header to sort ascending. * Click again to sort descending. * Use multi-column sorting, if enabled. {% hint style="info" %} Screenshot placeholder: column header showing sort indicator and the first few rows reordered. {% endhint %} #### Save the setup Most configurations save filter and sort changes automatically. When **Save as new view** appears, use it for variations. Use [Save Views and Templates](/getting-started/save-views-and-templates) when shared standards are required. Name the variation so it is obvious who it is for. For example: `Me — Open items`, `Team — Weekly review`. ### Best Practices * Add one filter at a time to validate results. * Duplicate shared views before large changes. * Keep shared view filters stable for reporting consistency. ### Summary Filters and sorting define the dataset and review order for a view. Use a Save View to reuse the configuration. Related: * [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) * [Save Views and Templates](/getting-started/save-views-and-templates) # Save Views and Templates Save, share, and reuse view setups so teams stay consistent. ### Overview Save Views capture a repeatable view setup. Templates standardize setup across Projects. {% hint style="info" %} Screenshot placeholder: view selector showing multiple saved views (private and team). {% endhint %} ### Key Concepts #### Save View A Save View typically includes visible columns, filters, sorting, and grouping. #### Template A template is a starting point for creating a new view. Templates help teams use consistent patterns. ### How It’s Used Use Save Views for daily review lists. Use templates for standard defaults across Projects. ### Benefits * Repeatable review lists without rebuilding filters * Standardized views across Projects for consistent governance ### Setup Steps #### What gets saved in a Save View Saved configuration typically includes: * Visible columns and their order * Filters * Sorting * Grouping {% hint style="info" %} Screenshot placeholder: a view showing columns + filters + grouping all active. {% endhint %} #### Create a Save View Most changes save to the current view automatically. When **Save as new view** appears, use it to create a clean copy. Use a clear name. Use names such as `Team — Weekly review` or `Tasks — This week`. {% hint style="info" %} GIF placeholder: customize a view, then use Save as new view, then rename it. {% endhint %} #### Naming conventions Consistent names keep the view selector usable. Use a simple pattern. `{Audience} — {Intent} — {Optional scope}` Recommended audiences: * `Team` for shared views * `Me` for personal views * `Export` for export-only views Use `Team` for stable defaults. Use `Me` for personal variations. Use `Export` when the view is designed for downloads. For example: * `Team — Weekly review` * `Team — Open items` * `Me — Open items` * `Export — Requirements (All)` * `Export — Tasks (Open)` {% hint style="warning" %} Avoid dates in names unless required. They go stale fast. {% endhint %} {% hint style="success" %} **Best practices** * Standardize names. Use a consistent prefix. For example: `Team — Weekly review`. * Keep team views minimal. Include only columns most people need. * Duplicate before major edits. Keep a baseline view. * Use templates for repeatability across Projects. * Review shared views quarterly. Archive or delete stale ones. {% endhint %} #### Share a Save View Set visibility so the right people can use it. * **Private** (single teammate) * **Team** (everyone in the project) {% hint style="info" %} Screenshot placeholder: view visibility options (Private vs Team) in the share modal. {% endhint %} #### Use templates (if enabled) Templates are starting points. They help teams use the same columns, filters, and grouping patterns. {% hint style="info" %} Screenshot placeholder: template picker or “Create from template” flow. {% endhint %} ### Best Practices * Standardize shared view names, then keep them stable. * Duplicate a shared view before major edits. * Review shared views quarterly and archive stale ones. ### Summary Save Views store repeatable view configurations. Templates provide standard starting points across Projects. Related: * [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) * [Exporting Data from Views](/getting-started/exporting-data-from-views) # Exporting Data from Views Export a view to a file for sharing, archiving, or offline analysis. ### Overview Exports convert the current view into a downloadable file. Exports typically respect filters and visible columns. {% hint style="info" %} Screenshot placeholder: export action in the view toolbar or overflow menu. {% endhint %} {% hint style="info" %} Tip: Use a dedicated export view named such as `Export — Requirements (All)`. {% endhint %} ### Key Concepts * **Export view**: a dedicated view used only for export definitions * **Scope**: current view vs selected rows vs all rows (availability varies) ### How It’s Used Use exports for offline review and stakeholder distribution. Use dedicated export views to avoid accidental scope changes. ### Benefits * Repeatable exports with predictable columns and filters * Cleaner handoffs to stakeholders outside Transform ### Setup Steps #### Naming pattern Use this naming pattern: `Export — {Object} ({Scope})` For example: * `Export — Requirements (All)` * `Export — Tasks (Open)` * `Export — UAT cases (Failed)` #### Export data from a view {% stepper %} {% step %} #### Open export Click **Export** (or the `⋮` menu → **Export**). {% endstep %} {% step %} #### Choose format Pick a format such as **CSV** or **XLSX**, if available. {% endstep %} {% step %} #### Confirm scope Confirm whether the export is for: * Current view * Selected rows * All rows {% endstep %} {% step %} #### Download Generate and download the file. {% endstep %} {% endstepper %} {% hint style="info" %} GIF placeholder: Export → choose CSV → download → open file showing headers match the view columns. {% endhint %} {% hint style="warning" %} **Best practices** * Treat the view as the export definition. Set columns and filters first. * Export from a dedicated “Export” view to avoid surprises. * Sanity-check row counts after download. Compare to the view total. * Be careful with sensitive fields. Export only required fields. {% endhint %} ### Best Practices * Treat export views as controlled definitions. * Confirm filters and row counts before distribution. * Remove sensitive columns before exporting. ### Summary Exports create files based on view configuration. Dedicated export views improve consistency and reduce mistakes. #### Troubleshooting
Export is missing columns Exports often include only visible columns. Add the columns to the view, then export again.
Export option is not available This is usually a permissions issue. Ask a Project admin for export access.
#### Next steps * [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) * [Creating and Customizing Board Views](/getting-started/creating-and-customizing-board-views) * [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) # Working with Views Learn how to create, customize, and share List, Board, and Gantt views. ### Overview Views define how data is displayed and reviewed. Views support repeatable reviews without rebuilding filters and columns. {% hint style="info" %} Screenshot placeholder: view selector showing List, Board, and Gantt options. {% endhint %} ### Key Concepts * **View type**: List, Board, or Gantt * **Save View**: stored view configuration for repeatable lists * **Visibility**: private vs shared (availability varies) ### How It’s Used Use List for dense editing and review. Use Board for workflow reviews. Use Gantt for timelines and sequencing. ### Benefits * Faster daily review through consistent layouts * Cleaner reporting through standardized filters and columns * Reduced errors from inconsistent manual filtering ### Setup Steps Start with List views. Add Board and Gantt after List patterns are stable. ### Best Practices * Standardize shared views with predictable naming. * Limit the number of shared views per Project. * Use dedicated export views for downloads. ### Summary Core guides: * [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) * [Creating and Customizing Board Views](/getting-started/creating-and-customizing-board-views) * [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Save Views and Templates](/getting-started/save-views-and-templates) * [Exporting Data from Views](/getting-started/exporting-data-from-views) # Copy of Transform Help Get an overview of Transform's features and how to use them. Transform helps teams accelerates business transformation by: * Maintaining a knowledge base of how the company runs * Governing the work that improves how the company runs Transform combines project management with people, process, and technology change management to enable unified and holistic digital transformation and business process improvement programs. Consultants use Transform for delivery across customer portfolios. ## Quick Start Complete initial setup quickly. {% stepper %} {% step %} ### New to Transform [What Is Transform](/getting-started/what-is-transform) — Value and problem framing [Core concepts and terminology](/getting-started/new-to-transform) {% endstep %} {% step %} ### Account Setup [Account Setup](/getting-started/account-setup) — Create a login and sign in {% endstep %} {% step %} ### Create an Organization [Create an Organization](/organizations-and-projects/create-an-organization) — Create an Organization scope {% endstep %} {% step %} ### Create a Project [Create a Project](/getting-started/create-a-project) — Create the first delivery container {% endstep %} {% step %} ### Add Teammates [Add Teammates](/organizations-and-projects/add-teammates) — Invite Teammates {% endstep %} {% step %} ### Understanding the Interface [Understanding the Interface](/getting-started/understanding-the-interface) — Tour the UI {% endstep %} {% endstepper %} ### First Steps Tutorials Step-by-step walkthroughs: * [Tutorial: Creating an Organization and Project](/getting-started/tutorial-creating-an-organization-and-project) * [Tutorial: Set Up a First Blueprint](/getting-started/tutorial-set-up-a-first-blueprint) * [Tutorial: Creating a First Transformation](/getting-started/tutorial-creating-a-first-transformation) * [Tutorial: Working with Views (List, Board, Gantt)](/getting-started/tutorial-working-with-views-list-board-gantt) * [Tutorial: Using Meeting Notetaker and Console](/getting-started/tutorial-using-meeting-notetaker-and-console) * [Tutorial: Using Analytics Dashboards](/getting-started/tutorial-using-analytics-dashboards) *** ## Core Workflows Content is organized by common delivery outcomes. {% stepper %} {% step %} ### Plan and Document a Project Define scope, structure, and requirements. * [**Understanding Organizations and Projects**](/organizations-and-projects/understanding-organizations-and-projects) — Scope model and structure * [**Create an Organization**](/organizations-and-projects/create-an-organization) — Create an Organization scope * [**Organization Settings and Management**](/organizations-and-projects/organization-settings-and-management) — Configure an Organization * [**Create Projects and the Details Page**](/organizations-and-projects/create-projects-and-the-details-page) — Start a project * [**Project Structure and Hierarchy**](/organizations-and-projects/project-structure-and-hierarchy) — Organize delivery work * [**Blueprint Fundamentals**](/blueprints/blueprint-fundamentals) — What blueprints are, and why they matter * [**What Are Blueprints?**](/blueprints/blueprint-fundamentals/what-are-blueprints) — Core concept * [**Creating Blueprints**](/blueprints/creating-blueprints) — Build a Blueprint * [**Processes**](/blueprints/creating-blueprints/processes) — Document business processes * [**Process Hierarchy**](/blueprints/creating-blueprints/process-hierarchy) — Organize processes * [**Create Systems**](/blueprints/systems-management/create-systems) — Map technology stack * [**System Types**](/blueprints/systems-management/system-types) — Understand system categories * [**Segmentation**](/blueprints/segmentation) — Segment Types and Segments {% endstep %} {% step %} ### Build & Prepare Your Deliverables Generate requirements, track changes, and prepare test plans. * [**Working with Transformations**](/transformations/working-with-transformations) — Create and manage transformation records * [**Requirements Generation**](/transformations/requirements) — Auto-generate requirements from blueprints * [**Requirements**](/transformations/requirements) — Create and refine requirements * [**Audit Trail**](/transformations/audit-trail) — Track changes and decisions * [**Creating Dependencies Between Requirements**](/transformations/creating-dependencies-between-requirements) — Link related requirements * [**Viewing Dependency Chains**](/transformations/viewing-dependency-chains) — See the full picture * [**Create and Assign Tasks**](/transformations/create-and-assign-tasks) — Build a task list * [**Task Dependencies**](/transformations/task-dependencies) — Link dependent tasks * [**Task Status Tracking**](/transformations/task-status-tracking) — Monitor progress * [**Create Test Cases**](/transformations/create-test-cases) — Define test scenarios * [**Test Organization and Views**](/transformations/test-organization-and-views) — Organize tests * [**Linking Tests to Requirements**](/transformations/linking-tests-to-requirements) — Trace tests to requirements {% endstep %} {% step %} ### Execute & Validate Run tasks, execute tests, and track progress. * [**Task Management**](/transformations/task-management) — Manage work items * [**Task Views and Organization**](/transformations/task-views-and-organization) — Review tasks in views * [**Testing**](/transformations/testing) — Execute and track tests * [**Test Organization and Views**](/transformations/test-organization-and-views) — Organize test execution * [**Getting Started with Analytics**](/analytics/getting-started-with-analytics) — Review progress signals * [**Creating Custom Dashboards**](/analytics/creating-custom-dashboards) — Build dashboards * [**Dashboard Widgets**](/analytics/dashboard-widgets) — Add charts and metrics * [**Creating Pivot Tables**](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/67Qn8nWFd8Ut4RBaJEWf) — Analyze data * [**Pivot Table Analysis**](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/Wr2U2uQWfmWomYUZHFJH) — Deep dive into metrics * [**Reports**](/analytics/reports) — Generate formal reports * [**Status Types and Meanings**](/transformations/status-types-and-meanings) — Understand status options * [**Custom Status Creation**](/transformations/custom-status-creation) — Create custom statuses for a workflow {% endstep %} {% step %} ### Collaborate & Manage Keep delivery teams aligned and maintain compliance. * [**Understanding Access Levels**](/organizations-and-projects/understanding-access-levels) — Who can do what * [**Add Teammates**](/organizations-and-projects/add-teammates) — Invite Teammates * [**User Roles and Permissions**](/organizations-and-projects/user-roles-and-permissions) — Manage permissions * [**Collaborating in Transform**](/collaboration-and-automation/collaborating-in-transform) — Work together * [**Comments and Mentions**](/collaboration-and-automation/comments-and-mentions) — Communicate in context * [**Following and Watching Items**](/collaboration-and-automation/following-and-watching-items) — Stay updated * [**Team Communication Tips**](/collaboration-and-automation/team-communication-tips) — Best practices * [**Notification Settings**](/collaboration-and-automation/notification-settings) — Manage notifications * [**Comments and History**](/collaboration-and-automation/comments-and-history) — Track activity * [**Understanding Activity Feeds**](/collaboration-and-automation/understanding-activity-feeds) — See what changed * [**Tracking Changes and Decisions**](/collaboration-and-automation/tracking-changes-and-decisions) — Maintain compliance {% endstep %} {% step %} ### Configure & Integrate Configure the Account and connect external systems. * [**Account Configuration**](/administration/account-configuration) — Manage Account configuration * [**Settings**](/administration/settings) — Configure settings * [**Connectors**](/administration/connectors) — Connect to other systems * [**Custom Fields**](/administration/custom-fields) — Create custom fields * [**Profile Configuration**](/getting-started/profile-configuration) — Profile settings * [**Appearance Settings**](/getting-started/appearance-settings) — Theme settings * [**API Tokens**](/api-and-development/api-tokens) — Manage API access * [**Creating and Managing API Tokens**](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/VgESexutegs3dEjn4t5T) — Generate tokens * [**Console Overview and Access**](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/IHr5D4941EfyTqBdCYqy) — Use the developer console * [**Console Features and Capabilities**](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/f6mM0HdSZi2Fc8RoDp6F) — Capabilities * [**Connecting Tools**](/integrations/connecting-your-tools) — Integrations overview * [**Business Tools**](/integrations/business-tools) — Connect business apps * [**Data & Analytics**](/integrations/data-and-analytics) — Connect data sources {% endstep %} {% endstepper %} *** ## Popular Articles Common guides, organized by task. ### Getting Started * [Create an Organization](/organizations-and-projects/create-an-organization) — Create an Organization and invite Teammates * [Create Projects and the Details Page](/organizations-and-projects/create-projects-and-the-details-page) — Organize delivery work * [Add Teammates](/organizations-and-projects/add-teammates) — Invite Teammates and manage roles ### Documenting Requirements & Workflows * [Blueprint Fundamentals](/blueprints/blueprint-fundamentals) — Understand what blueprints are and why they matter * [Creating Blueprints](/blueprints/creating-blueprints) — Build processes, systems, and segments to map a Project * [Requirements Generation](/transformations/requirements) — Automate requirement creation * [Create Processes](/blueprints/creating-blueprints/processes) — Document business processes * [Create Systems](/blueprints/systems-management/create-systems) — Map technology stack ### Managing Change & Progress * [Working with Transformations](/transformations/working-with-transformations) — Generate requirements, create tasks, build test cases, and manage versions * [Audit Trail](/transformations/audit-trail) — Track changes and decisions ### Tracking & Analyzing * [Getting Started with Analytics](/analytics/getting-started-with-analytics) — Review progress signals * [Creating Custom Dashboards](/analytics/creating-custom-dashboards) — Dashboards for governance * [Creating Pivot Tables](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/67Qn8nWFd8Ut4RBaJEWf) — Analyze data ### Team & Admin * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) — Understand access control * [Account Configuration](/administration/account-configuration) — Manage settings and integrations *** ## Quick Tips & Pro Tips ### Pro Tips * Use Save Views — save repeatable lists for governance reviews * Use Console — query decisions, approvals, and blockers using natural language ### Did You Know? * Meeting Notetaker captures decisions — meeting summaries can convert into requirements and tasks. [Meeting Notetaker](/ai/meeting-notetaker) * Console supports investigation — Console can retrieve sources for decisions and approvals. [Console AI Search](/ai/console-ai-search) {% hint style="warning" %} Audit Trail supports compliance — review history when modifying requirements. [Audit Trail](/transformations/audit-trail) {% endhint %} *** ## Need Help? If content is not found: | | | | -------------------------- | ----------------------------------------------------------------------------------------------------------- | | 🔧 **Troubleshooting** | Find solutions to common issues and error messages. [Open →](/troubleshooting/getting-help) | | 💬 **Transform Community** | Ask questions and share patterns. [Open →](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/wUeP36SGnqUnmv5Z7ghw) | | 📧 **Contact Support** | Get help from our support team. [Open →](/resources/contact-support) | | 📊 **System Status** | Check the current status of Transform services. [Open →](https://status.transform.ai/) | *** ## 🎓 Learn More ### Key Concepts * [Key Concepts and Terminology](/getting-started/key-concepts-and-terminology) — Understand Transform's vocabulary * [System Requirements](/getting-started/system-requirements) — Browser and system requirements * [Browser Compatibility](/getting-started/browser-compatibility) — Supported browsers ### Advanced Features (Coming Soon) * Automation — Automate repetitive workflows * Auto-Generated Deliverables — Auto-generate BRDs, SOWs, test plans, and UAT scripts * Document Management — Manage versions and templates * Replay — Review project history and catch up on missed context ### Explore More * [Search and Navigation](/getting-started/search-and-navigation) — Learn advanced search techniques * [How AI Powers Transform](/ai/how-ai-powers-transform) — Understand Transform's AI capabilities * [Using Global Search](/getting-started/using-global-search) — Find anything fast * [Connecting Tools](/integrations/connecting-your-tools) — Integrate with external systems *** ## 📞 Still Have Questions? * [Welcome Transformers — Start Here](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/wUeP36SGnqUnmv5Z7ghw) — Community onboarding * [Report a Bug](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/tHt9ZJolfMmKqrgjOMJk) — Bug reporting * [Submit Ideas & Feature Requests](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/tu1RWOGVCP3ZRaLduIH2) — Product feedback * [Contact Support](https://help.transform.ai/support) — Support routing *** ### Summary Help Center routes to onboarding, common workflows, and support. Common destinations: * Onboarding: [Start Here](/getting-started/start-here) * Tutorials: [First Steps Tutorials](/getting-started/first-steps-tutorials) * Governance search: [Console AI Search](/ai/console-ai-search) * Troubleshooting: [Getting Help](/troubleshooting/getting-help) * Support: [Contact Support](https://help.transform.ai/support) # Organizations Use Organizations to separate work by client, department, or business unit. ### Overview Organizations are the primary containers for separating work in Transform. They prevent cross-client mixing and support scoped access control. ### Key Concepts * **Organization scope**: container for Projects, Segment Types, and Segments * **Organization naming**: stable identifiers used across reporting and search * **Access at Organization scope**: shared access across multiple Projects ### How It’s Used Create one Organization per client or department. Create Projects inside the Organization for each initiative. Organizations are also the home for segmentation: * Segment Types and Segments are managed at the Organization level. * [Segmentation](/blueprints/segmentation) ### Benefits * Clear separation of work and governance boundaries * Cleaner access control for multi-Project delivery teams * Consistent reporting across Projects within a business boundary ### Setup Steps {% stepper %} {% step %} ### Create an Organization * [Create an Organization](/organizations-and-projects/create-an-organization) {% endstep %} {% step %} ### Create Projects inside the Organization * [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Configure Organization-level structure (optional) Define segmentation and standard reporting fields. {% endstep %} {% endstepper %} ### Best Practices * Keep Organization names stable and human-searchable. * Avoid abbreviations in Organization names unless required by policy. * Use segmentation only for real business dimensions that drive reporting. ### Summary Organizations separate work and define an access and reporting boundary. Projects inside an Organization contain delivery work items. Related: * [Understanding Organizations and Projects](/organizations-and-projects/understanding-organizations-and-projects) * [Projects](/organizations-and-projects/projects) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # Create an Organization Create an organization to separate work by client, department, or business unit. {% columns %} {% column %} **What is covered** * Create a new Organization * Name it for fast searching * Confirm access settings (if prompted) {% endcolumn %} {% column %} **At a glance** * **Time:** \~2–5 minutes * **Access:** Account Admin (or equivalent) {% endcolumn %} {% endcolumns %} ### Overview Organizations separate work by client, department, or business unit. They provide a boundary for access control and reporting. ### Key Concepts * **Organization**: container for Projects * **Organization scope access**: shared access across multiple Projects * **Segmentation**: Segment Types and Segments are managed at Organization scope ### How It’s Used Most Accounts use one Organization per client or department. Projects are created inside the Organization for each initiative. ### Benefits * Prevents cross-client or cross-department mixing * Simplifies access control for multi-Project teams * Improves reporting consistency within an Organization
### Setup Steps {% stepper %} {% step %} ### Open Organizations Open the **Organizations** page from the main navigation.
{% endstep %} {% step %} ### Create an Organization Click **New organization** (or **Add organization**).
{% endstep %} {% step %} ### Enter details Set: * **Name** (for example: `ACME Corp`) * **Description** (optional, one sentence) * **Visibility / access** (if shown) {% endstep %} {% step %} ### Submit Create the Organization.
{% endstep %} {% endstepper %} #### Prerequisites * Sign-in is working. * Permission exists to create Organizations. * Organization name is available. {% hint style="warning" %} If the option to create an Organization is not available, request access from an Account Admin. {% endhint %} ### Best Practices Keep names stable and searchable. Good patterns: * `Client — Program` (consulting) * `Department` (enterprise) Operational guidance: * Create Organizations early to simplify access control. * Keep naming consistent and avoid internal abbreviations. * Add Teammates after creation and use least-privilege roles. #### Troubleshooting
Organization creation is not available This is usually a permissions issue. Account Admin access (or equivalent) is often required. Ask an Account Admin to grant access or create the Organization.
### Summary Next steps: * [Create a Project](/getting-started/create-a-project) * [Add Teammates](/organizations-and-projects/add-teammates) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # Organization Settings and Management Manage Organization details, access patterns, segmentation, and the Projects inside the Organization. ### Overview Organization settings define how work is governed inside an Organization. This includes Organization details, segmentation, and Project management patterns. ### Key Concepts * **Organization details**: name and descriptive context used for search and reporting * **Organization scope**: boundary for Segments and Segment Types * **Organization-level access**: shared access across Projects (when enabled) ### How It’s Used Use Organization settings during initial rollout. Use them when adding new Projects or updating governance. ### Benefits * More consistent structure across Projects * Cleaner reporting through shared segmentation * Reduced access drift through scoped management ### Setup Steps {% stepper %} {% step %} ### Open the Organization Navigate to **Organizations**. Select the Organization to manage. {% endstep %} {% step %} ### Update Organization details Update the Organization name and description when business structure changes. Keep names stable and human-searchable. {% endstep %} {% step %} ### Configure segmentation (optional) Define Segment Types and Segments for reporting and scoping. * Segmentation {% endstep %} {% step %} ### Manage Projects inside the Organization Create new Projects for new initiatives. Archive Projects when delivery completes. * Create a Project {% endstep %} {% step %} ### Set up Interactions Routing (optional) Add the Organization's email domains on the **Interactions Routing** tab so synced meetings and emails with its people are filed here automatically. * [Interactions Routing](/organizations-and-projects/interactions-routing) {% endstep %} {% endstepper %} ### Best Practices * Keep Organization names stable and avoid abbreviations. * Use segmentation only for real business dimensions used for reporting. * Standardize Project naming and section structure across related initiatives. ### Summary Organization settings define governance patterns and reporting structure. Segmentation is managed at the Organization level. Related: * Organizations * Projects * Understanding Access Levels * [Interactions Routing](/organizations-and-projects/interactions-routing) # Interactions Routing Automatically file synced meetings and emails into the right Organization based on the email domains of the people on them. ### Overview Interactions Routing files synced meetings and emails into an Organization automatically. When the people on a meeting or email include someone from one of the Organization's email domains, Transform tags it with that Organization, and with a Project when one can be identified. For example, if the **Acme** Organization lists `acme.com`, a synced calendar meeting with `jane@acme.com` on the guest list lands in Acme without anyone filing it by hand. ### Key Concepts * **Email domains**: the Organization's own domains (for example `acme.com`). Routing only happens once at least one domain is added. * **Auto-route toggle**: a per-Organization switch. It is on by default, but has no effect until the Organization has a domain. * **Internal domains**: your own company's domains, set at the account level. People on these domains are ignored when routing, so your team being on a meeting never decides where it is filed. * **Default Auto-Routing Project**: an optional Project setting that names where routed items land inside the Organization. ### How It Works {% stepper %} {% step %} ### Collect the external participants For a **meeting**, Transform looks at every attendee. For an **email**, it looks at the sender and the visible recipients (From, To, and CC). Blind copies (BCC) are never used, so routing can never reveal who was blind-copied. Participants on your account's internal domains are skipped. {% endstep %} {% step %} ### Match domains to Organizations Each remaining participant's domain is compared against the email domains of Organizations that have auto-routing turned on. * **Exactly one Organization matches**: the meeting or email is filed there. * **No Organization matches**: nothing changes. * **Two or more Organizations match**: nothing changes. Transform never guesses between two customers, so the item stays unfiled for someone to place manually. Guests whose domain belongs to no Organization (a booked conference room, a contractor on gmail.com) are ignored. They neither route nor block routing. {% endstep %} {% step %} ### Pick a Project (when possible) Inside the matched Organization: 1. If one Project is marked as the **Default Auto-Routing Project**, the item lands there. 2. Otherwise, if the matched participants all belong to the same Project in that Organization, the item lands in that Project. 3. Otherwise, the item is filed to the Organization with no Project. {% endstep %} {% endstepper %} {% hint style="info" %} Routing applies when a meeting or email is first synced. Items that already exist are never re-filed, and a calendar sync that already targets a specific Organization or Project keeps that target. {% endhint %} ### Privacy and Visibility Routing files an item; it never widens who can read it. * An auto-routed **meeting** is created as **internal-only** and **restricted to attendees**, because the Organization was inferred rather than chosen by a person. Both settings can be changed on the meeting afterwards. * A routed email keeps the privacy it already had. Each person only sees the items they were on. ### Setup Steps {% stepper %} {% step %} ### Set your internal domains (once per account) Open **Settings** for your account and add your company's own domains under **Internal domains**. This keeps your team's addresses from affecting routing. {% endstep %} {% step %} ### Open the Organization Navigate to **Organizations** and select the Organization to configure. {% endstep %} {% step %} ### Open the Interactions Routing tab Select the **Interactions Routing** tab on the Organization detail page. {% endstep %} {% step %} ### Add the Organization's email domains Type a domain (for example `acme.com`) and select **Add**, or press Enter. Add every domain the customer uses. Changes save immediately. * Public email domains such as `gmail.com` cannot be added. * A domain can belong to only one Organization. Adding a domain that another Organization already claims is rejected. * If a domain is also one of your account's internal domains, the tab warns you: it will never route anything. {% endstep %} {% step %} ### Confirm auto-routing is on Make sure **Auto-route interactions to this organization** is switched on. Turn it off to stop routing to this Organization without removing its domains. {% endstep %} {% step %} ### Choose a default Project (optional) Open the Project that should receive routed items and switch on **Default Auto-Routing Project** in its properties. Only one Project per Organization can hold this setting; turning it on for one Project turns it off for the previous one. {% endstep %} {% endstepper %} ### Best Practices * Add all of a customer's domains (including subsidiaries and regional domains) to the same Organization. * Set a Default Auto-Routing Project for Organizations with a single active engagement, so routing is predictable. * Keep your account's internal domains up to date, especially after acquisitions or domain changes. ### Troubleshooting | Symptom | Likely cause | | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Nothing is being routed to the Organization | No domains added, the toggle is off, or the domain is also an internal domain. | | A meeting with the customer was not routed | Attendees from another Organization were also on it, or the meeting existed before the domain was added. | | Items land in the Organization but no Project | No Default Auto-Routing Project is set and participants' Project memberships don't point to a single Project. | | A routed meeting isn't visible to an external user | Auto-routed meetings start as internal-only and attendees-only. Change those settings on the meeting if needed. | ### Summary Add an Organization's email domains on its **Interactions Routing** tab, and Transform files matching meetings and emails into it automatically. Ambiguous matches are left unfiled, and routing never makes anything more visible. Related: * [Organization Settings and Management](/organizations-and-projects/organization-settings-and-management) * [Organizations](/organizations-and-projects/organizations) * [Meeting Notetaker](/ai/meeting-notetaker) * [Capturing Meetings Automatically](/ai/capturing-meetings-automatically) # Create Projects and the Details Page Create a Project, update key fields on the details page, and locate deeper settings. ### Overview Project details contain the basic fields used for naming, timeline, and reporting. Project Settings contains deeper configuration such as roles, fields, and connectors. ### Key Concepts * **Project details**: name, dates, status, and other high-level metadata * **Project Settings**: access control, fields, templates, automation, connectors ### How It’s Used Use Project details for quick metadata updates. Use Project Settings for governance and workflow configuration. ### Benefits * Cleaner reporting through accurate dates and status * Reduced configuration drift by separating details from settings ### Setup Steps {% stepper %} {% step %} ### Create a Project Use this guide when a Project does not exist yet: * [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Open Project details Open the Project. Open **Project details** (or the Project name menu), depending on UI configuration. {% endstep %} {% step %} ### Update core fields Keep these fields accurate: * **Name** * **Description** * **Start date / end date** * **Status** {% endstep %} {% step %} ### Locate deeper configuration Use Project Settings for configuration changes: * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) {% endstep %} {% endstepper %} ### Best Practices * Keep start and end dates aligned to the delivery plan. * Use consistent naming patterns across Projects. * Treat Project Settings changes as governed updates. #### Troubleshooting
Project details cannot be edited This is usually a permissions issue. Project Admin access may be required.
### Summary Project details are used for quick metadata updates. Project Settings is used for access control and workflow configuration. Related: * [Projects](/organizations-and-projects/projects) * [Add Teammates](/organizations-and-projects/add-teammates) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # Project Structure and Hierarchy Understand how Organizations, Projects, sections, and work items roll up for navigation and reporting. ### Overview Project structure defines how delivery work is organized inside a Project. A clear hierarchy makes navigation, reporting, and governance easier. ### Key Concepts * **Organization → Project**: top-level separation of work * **Project sections**: grouping mechanism for phases, sprints, and workstreams * **Work items**: requirements, tasks, tests, and artifacts * **Hierarchy**: parent-child relationships that support rollups ### How It’s Used Use sections to model delivery phases and workstreams. Use consistent naming to support search and reporting. ### Benefits * Faster navigation in large Projects * Cleaner timelines for Gantt views * Clearer ownership when sections map to workstreams ### Setup Steps {% stepper %} {% step %} ### Confirm Organization and Project boundaries Create one Organization per client or department. Create one Project per initiative. {% endstep %} {% step %} ### Define Project sections Create top-level sections for phases or workstreams. Add child sections for subphases and sprints. * [Project Sections](/organizations-and-projects/project-sections) {% endstep %} {% step %} ### Standardize fields used for reporting Add custom fields at Project scope. Use Organization-level Segmentation for cross-Project reporting. * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) * [Segmentation](/blueprints/segmentation) {% endstep %} {% endstepper %} ### Best Practices * Keep section names stable and unique within a Project. * Use the same phase names across related Projects. * Keep workstream sections aligned to real ownership boundaries. ### Summary Project hierarchy is built from Organization and Project boundaries plus section structure. Consistent structure improves navigation and reporting. Related: * [Organizations](/organizations-and-projects/organizations) * [Projects](/organizations-and-projects/projects) * [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) # Project Settings and Configuration Control access, fields, defaults, and integrations for a single project. {% columns %} {% column %} **What is covered** * Project details and defaults * Teammates, roles, and permissions * Custom fields * Integrations, templates, and automation (if enabled) {% endcolumn %} {% column %} **Permissions** Most settings require **Project Admin** access. Some options are **account-level**. For example: statuses and shared fields. {% endcolumn %} {% endcolumns %} ### Overview Project settings shape how a single Project works. They affect access, structure, and day-to-day workflows. ### Key Concepts * **Scope**: changes apply at Account, Organization, or Project scope * **Teammate roles**: permissions granted within a scope * **Custom fields**: structured metadata for reporting and filtering * **Templates and automation**: repeatable defaults and trigger-based actions (if enabled) ### How It’s Used Use this page when setting up a new Project. Use it for governance changes that affect access and reporting. ### Benefits * More consistent workflows for delivery teams * Cleaner reporting through standardized fields * Reduced access drift through defined roles ### Setup Steps {% stepper %} {% step %} ### Open the project Open the Project to configure. {% endstep %} {% step %} ### Open settings Click the **Settings** gear icon in the project navigation. {% endstep %} {% step %} ### Confirm permissions Project Admin access is required in most configurations. Some Accounts also use an **Owner** role. {% endstep %} {% endstepper %} {% hint style="info" %} Screenshot placeholder: Project navigation with the Settings (gear) icon. {% endhint %} #### Project settings menu Common sections: * **Project details** * **Team / members** * **Custom fields** * **Connectors / integrations** * **Templates** (if enabled) * **Automation** (if enabled) * **Advanced** (if enabled) {% hint style="info" %} Screenshot placeholder: Settings sidebar showing the menu items above. {% endhint %} #### Project details **Project information** Typical fields: * **Name** and **description** * **Color / icon** * **Project key** (short identifier used in item IDs) * **Start date** and **end date** {% hint style="info" %} Screenshot placeholder: Project details form (name, description, key, dates). {% endhint %} **Visibility and privacy** Options vary by Account configuration: * **Private**: only invited Teammates * **Team**: all Teammates in the Account * **Public**: anyone with the link (if enabled) **Status** Common statuses: * Active * On hold * Complete * Archived **Default view** Set the first view Teammates land on. Common defaults: **List**, **Board**, **Gantt**. #### Team, roles, and permissions **Add Teammates** {% stepper %} {% step %} ### Open the team page Go to **Settings → Team** (or **Members**). {% endstep %} {% step %} ### Add a person Click **Add member** or **Invite**. {% endstep %} {% step %} ### Select Teammates Select existing Teammates, or invite a new Teammate. {% endstep %} {% step %} ### Assign a role Choose the role they should have in this project. {% endstep %} {% endstepper %} {% hint style="info" %} Screenshot placeholder: Project members list with role dropdowns. {% endhint %} **Roles (typical)** Transform role names vary by Account configuration. These are the most common: * **Admin**: manage settings, access, and content * **Member**: create and edit work items * **Viewer**: read-only For scope vs role, see [Understanding Access Levels](/organizations-and-projects/understanding-access-levels). **Permissions to review** * Set who can create tasks * Set who can delete tasks * Set who can invite new Teammates * Set who can change project settings * Set who can archive the project {% hint style="info" %} Screenshot placeholder: Permission controls (toggles/checkboxes). {% endhint %} #### Custom fields Custom fields standardize how teams capture metadata. **Create a custom field** {% stepper %} {% step %} ### Open custom fields Go to **Settings → Custom fields**. {% endstep %} {% step %} ### Add a field Click **Add custom field**. {% endstep %} {% step %} ### Configure the field Set: * **Name** (for example: `Client`, `Workstream`, `Phase`) * **Type** * Text (single line) * Text (multi-line) * Number * Date * Dropdown (single select) * Multi-select * Checkbox * URL * Currency * **Required** (optional) * **Default value** (optional) {% endstep %} {% endstepper %} {% hint style="info" %} GIF placeholder: Add custom field → name it → pick type → save. {% endhint %} **Manage custom fields** * Reorder fields by dragging * Hide fields from views * Archive unused fields (data stays) * Edit options for dropdowns and multi-selects {% hint style="info" %} Screenshot placeholder: Drag-and-drop reorder in the custom fields list. {% endhint %} **Best practices** * Avoid duplicates of built-in fields. * Keep names consistent across Projects. * Document meanings in an internal SOP. * Keep the list short. Too many fields slow everyone down. For deeper setup, see [Custom Fields](/administration/custom-fields). #### Workflow and statuses Statuses and shared workflow fields are often **Account-level**. Set them once, then reuse them across Projects. {% stepper %} {% step %} ### Open statuses Go to Account settings for **Statuses**. {% endstep %} {% step %} ### Review current status columns Review current status columns. {% endstep %} {% step %} ### Update statuses Add, edit, or remove: * **Name** (for example: `Discovery`, `Build`, `UAT`) * **Color** * **Type** (Not started / In progress / Complete) {% endstep %} {% endstepper %} #### Workflow rules (if enabled) * Define which statuses can transition to which * Set a default status for new work * Align on what “complete” means #### Automation rules (if enabled) * Auto-assign tasks when status changes * Send notifications on specific transitions * Update fields when conditions match #### Templates (if enabled) Templates speed up repeatable work. **Create a task template** {% stepper %} {% step %} ### Open templates Go to **Settings → Templates**. {% endstep %} {% step %} ### Create a template Click **Create template**. {% endstep %} {% step %} ### Configure defaults Set: * Template name * Default title and description * Default assignee (optional) * Default status and fields * Subtasks (optional) {% endstep %} {% step %} ### Save Save template. {% endstep %} {% endstepper %} **Use a template** When creating a new task, pick **From template**. Then adjust the task as needed. {% hint style="info" %} GIF placeholder: Create task → From template → pick template → fields prefill. {% endhint %} For example: * Customer onboarding * Bug report * Feature request * Meeting follow-up #### Automation (if enabled) Automation applies simple trigger → action rules. **Create an automation rule** {% stepper %} {% step %} ### Open automation Go to **Settings → Automation**. {% endstep %} {% step %} ### Create a rule Click **Create automation rule**. {% endstep %} {% step %} ### Define trigger and action For example: * Triggers: task created, status changed, due date approaching, field updated * Actions: assign owner, add comment, update field, send notification, create subtask {% endstep %} {% endstepper %} For example: * Status = `Ready for review` → assign to project lead * Priority = `High` → send a notification to a messaging channel * Overdue by 2 days → notify assignee and manager #### Connectors / integrations Connectors link a Project to external tools. **Configure a connector** Go to **Settings → Connectors**. Select a service and complete the authentication flow. {% hint style="info" %} Screenshot placeholder: Connectors list (notifications, calendar, document storage, and other external tools). {% endhint %} Typical connector patterns include: * Notifications to messaging or email tools * Calendar sync for due dates * Document storage links {% stepper %} {% step %} ### Select a service Open a connector to enable. {% endstep %} {% step %} ### Authenticate Complete authentication and approve permissions. {% endstep %} {% step %} ### Configure and test Set options. Then run a test event if available. {% endstep %} {% endstepper %} For account-wide integrations, see [Connectors](/administration/connectors). #### Archive and delete **Archive a Project** {% stepper %} {% step %} ### Open advanced settings Go to **Settings → Advanced**. {% endstep %} {% step %} ### Archive Select **Archive project**. {% endstep %} {% step %} ### Confirm Confirm archival. {% endstep %} {% step %} ### Result Archived projects are hidden, but restorable. {% endstep %} {% endstepper %} **Delete a Project** {% stepper %} {% step %} ### Permissions Only available to Project Admins or Account Owners. {% endstep %} {% step %} ### Open advanced settings Go to **Settings → Advanced**. {% endstep %} {% step %} ### Delete Select **Delete project**. {% endstep %} {% step %} ### Confirm Confirm deletion (this cannot be undone). {% endstep %} {% step %} ### Result All tasks, comments, and history are permanently deleted. {% endstep %} {% endstepper %} {% hint style="danger" %} Deletion is permanent. Archive when restoration may be required. {% endhint %} ### Best Practices #### When setting up a new Project * Set up custom fields before importing or creating many tasks. * Pick a default view that matches the team’s workflow. * Add key Teammates early, with least-privilege roles. #### Ongoing maintenance * Archive fields you no longer use. * Review automation rules quarterly. * Keep naming conventions consistent across Projects. #### Team alignment * Make one person accountable for configuration changes. * Collect feedback before changing shared statuses or fields. * Document field definitions and “done” criteria. ### Summary Project Settings control access, fields, defaults, automation, and connectors for a Project. Treat configuration changes as governed updates. Keep shared settings stable. Related: * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [Add Teammates](/organizations-and-projects/add-teammates) * [Custom Fields](/administration/custom-fields) * [Connectors](/administration/connectors) * [Working with Views](/getting-started/working-with-views) * [Statuses](/transformations/statuses) # Project Sections Organize project work into phases, sprints, and workstreams. ### Overview Project sections group work inside a Project. They support predictable navigation and timeline planning. ### Key Concepts #### Project section A project section is a container inside a Project. Sections group work into phases, sprints, or workstreams. ### How It’s Used Sections are flexible. Common patterns: * **Phases**: Plan, Design, Build, Test, Deploy * **Subphases**: nested under a parent section * **Sprints**: Sprint 1, Sprint 2, Sprint 3 * **Workstreams**: Change Management, Data Migration, Integrations * **Milestones** or other stages ### Modeling phases and sprints in Transform Transform does not use dedicated “Phase”, “Subphase”, or “Sprint” object types. Use sections instead: * **Phase** → top-level section * **Subphase** → child section under a parent * **Sprint** → section named by sprint (for example: `Sprint 2`) * **Workstream** → section grouped by functional area ### Section fields and behavior Typical section fields: * **Name** * **Parent section** (for nesting) * **Start date / end date** (for timeline planning) * **Status** (if enabled) * **Budget** (if enabled) {% hint style="info" %} For Gantt usage, set section start and end dates early. {% endhint %} ### Benefits * Predictable navigation for large Projects * Cleaner timelines in Gantt views * Clearer ownership when sections map to workstreams ### Setup Steps {% stepper %} {% step %} ### Create top-level sections Create sections for major phases or workstreams. {% endstep %} {% step %} ### Add child sections (optional) Nest sections for subphases and sprints when hierarchy is needed. {% endstep %} {% step %} ### Set section dates Set start and end dates for timeline planning and Gantt visibility. {% endstep %} {% endstepper %} ### Sections on the Gantt chart When a section has start and end dates, it shows as a bar on the Gantt chart. This lets you see phases and sprints alongside individual tasks. Tip: In many setups, you can adjust section dates directly in Gantt. ### Best Practices * Use **top-level sections** for major phases or workstreams. * Use **child sections** for subphases and sprints. * Keep section names **unique within a Project**. * Add **dates** so timelines stay accurate. * Use a consistent naming pattern across Projects. ### Summary Project sections group work into phases, sprints, and workstreams. Section dates enable clear Gantt timelines. Related: * [Project Structure and Hierarchy](/organizations-and-projects/project-structure-and-hierarchy) * [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) * [Create and Assign Tasks](/transformations/create-and-assign-tasks) # Understanding Access Levels Learn how access scope works (Account, Organization, Project) for assigning the right roles. ### Overview Access levels define what a Teammate can see and do. Access is assigned by scope, then constrained by role.
### Key Concepts * **Scope**: visibility boundary (Account, Organization, Project) * **Role**: permission set within a scope * **Mixed membership**: different roles for the same Teammate across scopes ### How It’s Used Use scope to limit what is visible. Use roles to limit what actions are permitted. ### Benefits * Clear visibility boundaries * Reduced risk from over-scoped access * Cleaner governance through predictable admin assignment ### Setup Steps #### Access scope (Account, Organization, Project) #### Account level Account access is the broadest scope. It spans every Organization and Project. **Good fit for** * System admins * Leaders who need global visibility * People managing multiple Organizations **What they can do** * See all Organizations and Projects * Manage Account settings * Add or remove Teammates anywhere **Example** For example: a transformation office leader needs visibility across all Organizations. #### Organization level Organization access is a department or business unit scope. It includes every Project inside that Organization. **Good fit for** * Department heads * Team leads for one division * Consultants working in one area **What they can do** * See all Projects in the Organization * Manage Teammates in the Organization * Cannot see other Organizations by default **Example** For example: a department lead needs visibility for one Organization only. #### Project level Project access is the narrowest scope. It limits someone to a single initiative. **Good fit for** * Project team members * External stakeholders * Anyone who should only see one project **What they can do** * Work inside that Project * Cannot see other Projects in the Organization **Example** For example: a workstream contributor needs visibility for one Project only. #### Roles at any scope Role answers one question. “What can they do there?” {% hint style="info" %} \[SCREENSHOT: Role selection dropdown showing current role options] {% endhint %} Role names vary by Account configuration. Common patterns include: * **Owner**: Hold broad control within the assigned scope, such as a Project or Organization. Edit, delete, assign, and manage work in that scope. * **Administrator**: Full administrative control across the Account. Manage Teammates, roles, billing, custom fields, and global settings. * **Project Manager**: Manage work at Project scope. Create and update Projects, assign tasks, manage timelines, configure workflows, and invite Teammates to specific Projects. No Account-wide admin access. * **Consultant**: Contribute to delivery work without sensitive admin access. Edit entities, such as requirements and solutions, and collaborate inside assigned Projects. * **Client Collaborator**: Support shared delivery with limited access. View and make limited edits to shared Projects, Artifacts, and discussions without broader internal access. * **Client Tester**: Focus on testing activity. View test cases, execute tests, and provide feedback without changing core Project structure. * **Member**: Handle day-to-day delivery work. Create, edit, and view assigned Projects, tasks, and entities without managing Teammates or structural settings. * **Viewer**: Review work in read-only mode. View Projects, reports, dashboards, and entity details without creating or editing content. #### Account-level global roles These roles apply across the full Account. * **Account Administrator**: global permission to everything. Cannot be archived, hidden, or deleted. * **Managing Partner**: global permission to everything. Applies across all Organizations and all Projects, including external access. #### Organization-scoped delivery roles These roles apply across all Projects within assigned Organizations. * **Project Manager**: Project administration scoped to assigned Organizations. * **Consultant**: full permissions scoped to assigned Organizations. #### Client-facing roles These roles are used for client or external participants. * **Client Collaborator**: edit access on assigned Organizations and Projects. * **Client Tester**: edit access on Test Cases only. View-only on everything else. Enable **External** when assigning either client-facing role. #### Explicit read-only role * **View Only**: read-only access wherever explicitly added. No Organization-wide or Project-wide access by default. #### Mixed membership One person can have different roles in different places. This is called **mixed membership**. **Example** For example: one Teammate can be an Account Admin, an Organization Member, and a Project Viewer. For example: one Teammate can be a **Managing Partner** across the Account and **View Only** on a specific client-facing area. Why it matters: * Least-privilege access is possible without blocking delivery work. * Stakeholders can be kept read-only. * Duplicate Teammate records are avoided. #### Add Teammates For the full flow, see [Add Teammates](/organizations-and-projects/add-teammates). **Option 1: with login access (invited Teammates)** These people will log in to Transform. {% stepper %} {% step %} ### Choose the right scope Add them at Account, Organization, or Project. {% endstep %} {% step %} ### Open Teammates Go to **Teammates** at that scope. {% endstep %} {% step %} ### Add and invite Enter email. Pick role. Send the invitation. {% endstep %} {% endstepper %} After an invitation is sent: * An email invitation is delivered. * The Teammate accepts and signs in. * The Teammate appears in the Teammates list. **Option 2: without login access (stakeholders or contacts)** These people are tracked. They do not log in. {% stepper %} {% step %} ### Choose the scope Add them at the level they should be associated with. {% endstep %} {% step %} ### Add without inviting Enter email. Pick role. Keep invitations off. {% endstep %} {% endstepper %} {% hint style="info" %} Email is required. Use an Organization-approved placeholder email when required. {% endhint %} #### Picking the right access level Start with scope. Then pick a role. * Visibility across all departments → **Account** * Visibility for one department → **Organization** * Visibility for one initiative → **Project** Then choose a role: * Manage Account-wide access and settings → **Account Administrator** * Manage Project delivery, assignments, and workflows → **Project Manager** or **Owner** * Create and edit delivery work → **Consultant** or **Member** * Review shared work or execute tests with limited edit rights → **Client Collaborator** or **Client Tester** * Read-only visibility → **Viewer** * Global administration across the account → **Account Administrator** or **Managing Partner** * Project administration across assigned Organizations → **Project Manager** * Delivery work across assigned Organizations → **Consultant** * Client-facing editing → **Client Collaborator** * Client-facing test execution → **Client Tester** * Read-only visibility → **View Only** #### Common setups #### Consulting firm with multiple clients * Account: delivery organization * Organization: each client * Project: each engagement Typical access: * Consultants: Project access with **Consultant** or **Project Manager** * Client sponsors: Organization access with **Client Collaborator** or **Viewer** * Leadership: Account access with **Account Administrator** or **Viewer** * Consultants: **Consultant** or **Project Manager**, based on responsibility * Partners: **Managing Partner** * Leadership: **Account Administrator** or **Managing Partner** #### Large enterprise transformation * Account: the enterprise * Organization: IT, Finance, Ops, HR * Project: each initiative Typical access: * Department heads: Organization access with **Owner** or **Viewer** * Project managers: Project access with **Project Manager** * Transformation office: Account access with **Account Administrator** #### Small company transformation * Account: the company * Organization: one default org * Project: workstreams Typical access: * Leadership: Account access with **Account Administrator** or **Owner** * Team members: Project access with **Member** or **Consultant** * Leadership: **Account Administrator** or **Managing Partner** * Team members: **Consultant** or **View Only** #### Managing access over time **Change a Teammate role** {% stepper %} {% step %} ### Open Teammates Go to the right Account, Organization, or Project. {% endstep %} {% step %} ### Update the role Use the row menu. Choose **Change role**. {% endstep %} {% endstepper %} {% hint style="info" %} \[GIF: Changing a teammate's role from View Only to Consultant] {% endhint %} **Remove access** {% stepper %} {% step %} ### Remove at the right scope Removing at the Account level removes access everywhere below it. {% endstep %} {% endstepper %} #### Review access regularly Do this monthly. Do this after major delivery milestones. Look for: * Contractors who rolled off * Stakeholders who only need **View Only** * People with broad access who no longer need it ### Best Practices * Start with the least access that supports delivery needs. * Enable **External** for client-facing roles. * Limit **Account Administrator** and **Managing Partner** access to a small set of leaders. * Keep roles updated as people change responsibilities. ### Troubleshooting
Project access is missing * Confirm the correct Organization is selected. * Ask an Admin to add access at Project or Organization scope. * Check whether the Project was archived.
Someone has too much access * Reduce scope first (Account → Organization → Project). * Then reduce role to a narrower option, such as **Managing Partner** → **Project Manager** → **Consultant** → **View Only**.
Many Teammates must be added * Add them individually. * Use a standard onboarding checklist. * Keep roles consistent by team.
Multiple emails across scopes Each Teammate record uses a single email address across the Account.
### Summary Access is assigned at Account, Organization, or Project scope. Roles constrain actions within the selected scope. Mixed membership supports least privilege across multiple initiatives. Related: * [Add Teammates](/organizations-and-projects/add-teammates) * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) * [Organization Settings and Management](/organizations-and-projects/organization-settings-and-management) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) # Add Teammates Invite Teammates and manage access by scope (Account, Organization, Project). {% columns %} {% column %} **What is covered** * Invite Teammates to Transform * Choose the right access level (Account, Organization, Project) * Assign a role * Update roles or remove access later {% endcolumn %} {% column %} **At a glance** * **Time:** \~3–5 minutes * **Access:** Account/Organization/Project Admin * **Prerequisites:** Teammate email addresses {% endcolumn %} {% endcolumns %} ### Overview Adding Teammates grants access at a specific scope. Start with the lowest scope that supports required visibility. Use [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) before inviting Teammates. ### Key Concepts * **Scope**: what can be seen (Account, Organization, Project) * **Role**: what can be done within scope * **Mixed membership**: one Teammate can hold different roles at different scopes ### How It’s Used Use Account scope for cross-Organization visibility. Use Organization scope for multi-Project teams in one Organization. Use Project scope for initiative teams and external collaborators. ### Benefits * Cleaner governance through scoped access * Reduced risk from over-scoped permissions * Easier onboarding through standard roles ### Setup Steps #### Prerequisites * Admin access exists at the scope used for invitation. * Teammate email addresses are available. {% hint style="warning" %} If **Teammates** is not available, permissions at the current scope are missing. {% endhint %} #### 1) Pick the scope Choose the level based on what they should see. * **Account**: access across every Organization and Project * **Organization**: access to one Organization and its Projects * **Project**: access to one Project only {% hint style="warning" %} Account-level access is broad. Use it sparingly. {% endhint %}
#### 2) Invite a Teammate Use the path that matches the current scope. {% tabs %} {% tab title="From Account or Organization settings" %} {% stepper %} {% step %} #### Open Settings Open the Account or Organization. Open **Settings**. {% endstep %} {% step %} #### Open Teammates Select **Teammates**. {% endstep %} {% step %} #### Invite Click **Invite teammate** (or **Add teammate**). {% endstep %} {% step %} #### Enter email and role Enter an email address. Choose a role. {% endstep %} {% step %} #### Send Send the invite. {% endstep %} {% endstepper %} {% endtab %} {% tab title="From a Project" %} {% stepper %} {% step %} #### Open the Project Open a Project. {% endstep %} {% step %} #### Open Share Click **Share** (or the team icon). {% endstep %} {% step %} #### Enter email and role Enter an email address. Choose a role. {% endstep %} {% step %} #### Send Send the invite. {% endstep %} {% endstepper %} {% hint style="info" %} GIF placeholder: Project → Share → email → role → Send. Keep it under 10 seconds. Crop to the Share modal. {% endhint %} {% endtab %} {% endtabs %} {% hint style="info" %} If **Teammates** is not available, admin access at that scope is missing. {% endhint %} #### 3) Choose a role Start with the narrowest role that supports the delivery need. Typical roles: Current roles: * **Account Administrator**: global permission to everything. Cannot be archived, hidden, or deleted. Applies across all Organizations and all Projects. * **Managing Partner**: global permission to everything. Applies across all Organizations and all Projects, including external access. * **Project Manager**: Project administration scoped to assigned Organizations. Applies across all Projects within those Organizations. * **Consultant**: full permissions scoped to assigned Organizations. Applies across all Projects within those Organizations. * **Client Collaborator**: edit access on assigned Organizations and Projects. Enable **External** when assigning this role. * **Client Tester**: edit access on Test Cases only. View-only on everything else. Enable **External** when assigning this role. * **View Only**: read-only access wherever explicitly added. No Organization-wide or Project-wide access by default. {% hint style="warning" %} The **External** toggle distinguishes client-facing roles from internal roles. Enable it for **Client Collaborator** and **Client Tester**, and for any Teammate who is a client or external user. {% endhint %} Role names vary by Account configuration. Common patterns include: * **Account Administrator**: Full administrative control across the Account. Manage Teammates, roles, billing, custom fields, and global settings. * **Project Manager**: Manage work at Project scope. Create and update Projects, assign tasks, manage timelines, configure workflows, and invite Teammates to specific Projects. No Account-wide admin access. * **Consultant**: Contribute to delivery work without sensitive admin access. Edit entities, such as requirements and solutions, and collaborate inside assigned Projects. * **Client Collaborator**: Support shared delivery with limited access. View and make limited edits to shared Projects, Artifacts, and discussions without broader internal access. * **Client Tester**: Focus on testing activity. View test cases, execute tests, and provide feedback without changing core Project structure. * **Owner**: Hold broad control within the assigned scope, such as a Project or Organization. Edit, delete, assign, and manage work in that scope. * **Member**: Handle day-to-day delivery work. Create, edit, and view assigned Projects, tasks, and entities without managing Teammates or structural settings. * **Viewer**: Review work in read-only mode. View Projects, reports, dashboards, and entity details without creating or editing content. For role details, see [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions). #### 4) Invitation result * They receive an email invitation. * They accept and create or sign into Transform. * Their status changes from **Invited** to active.
#### 5) Manage access later Open **Teammates**. Find the Teammate. Click `⋮`. Then: * Change the role * Resend the invite * Remove access {% hint style="success" %} Run a quick access review each month. Remove access when delivery work completes. {% endhint %}
Optional: track stakeholders without login access Some Accounts support contact-style Teammates. They show up in lists but do not receive a login invitation. If the option is not available, skip it.
### Best Practices * Start with Project scope for external collaborators. * Limit Account scope to admins and cross-Organization leaders. * Standardize role names and definitions in an internal SOP. * Review access monthly and after major milestones. #### Troubleshooting
Teammates is not available * Confirm current scope (Account, Organization, Project). * Confirm admin permissions exist at that scope. * Ask an admin to grant access or add the Teammate.
Invite email is not received * Confirm the email is spelled correctly. * Ask the recipient to check spam and quarantine. * Resend the invite from the teammate list, if available.
Incorrect scope was assigned Two options: * Change their role at the current level. * Remove them and re-add them at the correct level. Mixed membership is normal. Someone can have different roles at different levels.
### Summary After invitation: * The Teammate appears in the teammate list. * Status shows **Invited** until accepted. * Role is visible next to the Teammate name. Related: * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) * [Teammate Access Requests](/organizations-and-projects/teammate-access-requests) * [Create and Assign Tasks](/transformations/create-and-assign-tasks) # Teammate Access Requests Ask for a teammate to be added to or removed from an Organization or Project, and approve or reject those requests. {% columns %} {% column %} **What is covered** * Request access for a new person or an existing contact * Request a teammate's removal from an Organization or Project * Review, approve, and reject requests * Who can approve, and what approving changes {% endcolumn %} {% column %} **At a glance** * **Time:** \~1–2 minutes per request * **Access:** **Request Access** to raise requests; **Give Access** to decide them * **Prerequisites:** the person's email address, or their row on the Teammates list {% endcolumn %} {% endcolumns %} ### Overview Teammates who can't add or remove people directly can now **ask** for it. The right approvers decide in one click from their Inbox or from the **Access Requests** list. * **Request Access**: ask for a person to be added to an Organization or Project. Type anyone's email, or pick a contact already on the Teammates list. If the email belongs to someone already in your Account, Transform recognizes them instead of adding them twice. * **Request Removal**: ask for a teammate to be removed from one Organization or Project. Their account and other memberships stay untouched. * **Review, Approve, Reject**: approvers see each request with the requested role and note, can adjust the role, and decide. It's built for Client Collaborators and Project Managers who staff Projects day to day, and for the administrators who govern access. ### Benefits * **No more dead-end buttons.** People without permission used to see **Invite User** and get an error. Now they see **Request Access** instead. * **Built for volume.** Approvers can bulk-approve a queue of requests. Requesters can request access for many contacts at once. * **Safe by default.** Approving runs the same checks as a direct invite, so nobody gets more access than the approver could grant themselves. * **Everyone stays informed.** Approvers are notified as soon as a request is raised. The requester is notified when it's decided. ### How a request moves 1. **Raise:** the requester submits a request from **Teammates**. 2. **Notify:** everyone who can approve it gets an Inbox notification. 3. **Decide:** the first approver to approve or reject closes it for everyone, and the requester is notified. The requester can cancel the request any time before a decision. ### Request access or a removal {% stepper %} {% step %} #### Open Teammates Open the Organization or Project and go to **Teammates**. {% endstep %} {% step %} #### Choose who the request is for * **Anyone, by email:** click **Request Access** in the toolbar. Enter their email; name and a note are optional. This works for new people and for teammates who already use Transform elsewhere in your Account: the email is matched to them on approval, and they keep their current role. * **A contact already on this list (added, but never invited):** open the row menu and choose **Request Access**. * **Remove someone:** open a member's row menu and choose **Request Removal**. This removes them from this Organization or Project only. * **Many contacts at once:** select their rows and choose **Request Access** in the selection bar. One role and note apply to all. {% endstep %} {% step %} #### Pick a role For access requests, choose the role to request. It's required whenever the picker lists roles. Removal requests have no role. {% endstep %} {% step %} #### Send Click **Send Request**. The row shows **Request pending**, and you can choose **Cancel request** from the same menu. {% endstep %} {% endstepper %} {% hint style="info" %} Follow your requests under **Access Requests** in the navigation, and watch your Inbox for the decision. {% endhint %} ### Review requests {% stepper %} {% step %} #### Open the request Open the Inbox notification, or go to **Access Requests**. It sits in Account navigation, in an Organization's **Current Blueprint** group, and in a Project's **Governance** group, each with a pending count. {% endstep %} {% step %} #### Decide Choose **Approve** to accept the suggested role, **Review** to change the role or its scope first, or **Reject** with an optional note. {% endstep %} {% step %} #### Clear a queue (optional) Select several rows and choose **Approve** or **Reject** in the selection bar. A confirmation appears first, then a summary of what succeeded. {% endstep %} {% endstepper %} ### Details and rules Two role permissions control the feature: **Request Access** lets someone raise requests, and **Give Access** lets someone decide them. Admins can turn either on or off per role in the role editor. #### Who can approve requests Anyone whose role has the **Give Access** permission can approve or reject requests, as long as: * **It covers the request's scope.** Give Access applies to the request's Organization or Project. For a request on an Organization, it must cover the whole Organization. * **They can make the change.** The same role can add teammates there (for invite requests) or edit teammates there (for removal requests). Approving performs that change on the approver's behalf. * **It's an internal role.** Give Access on a client (External) role doesn't allow approving. Everyone who meets these conditions is notified of new requests and can approve or reject them. Someone with Give Access who can't add or edit teammates there can see the requests on the **Access Requests** list, but can't decide them. {% hint style="success" %} To make someone an approver, turn on **Give Access** for their role in the role editor, and make sure that role can add or edit teammates in the Organizations or Projects they should approve for. {% endhint %} #### Roles and scope * **Suggested role:** the role the requester picked, or the requester's own role if they didn't pick one. Approvers can change it with **Review**. * **Limited to the request's scope:** by default, access is restricted to the Organization or Project the request came from. * **Outside email domains:** people whose email isn't on the Account's internal domains can only get client (External) roles, and their access always stays limited to that scope. * **People who already have a role keep it.** Approving adds the new Organization or Project to their current access. See the next section. * **Broader access:** only approvers who can add teammates across the whole Account can approve without the scope limit. #### Requesting access for someone already in Transform If the email you type belongs to a teammate who already has a role, they keep that role. The role picked in the request is not applied. **When you send the request** * The role picker still appears, and the role you pick is saved and shown to approvers. * The email-domain rule still applies: internal roles can't be requested for outside email domains. **When it's approved** * **Role:** unchanged. Approvers see "already has this role; approving keeps it" instead of a role picker, and can't choose a different role or remove the scope limit. * **Access:** their current role is extended to the new scope. * Already covers the whole Account or that Organization: nothing changes. * Covers only some Projects and the request is for the Organization: it now covers the whole Organization. * Request is for a Project they can't reach yet: that Project is added. * A different Organization: it's added alongside their current access. * **Membership:** they're added to the Organization or Project if they weren't a member. * **Invitation:** active teammates get no new invitation. Contacts who were never invited do get one. {% hint style="info" %} **Exception:** an existing contact with no role is treated like a new person. They get the requested role, or the requester's own role if that one is no longer available, limited to the request's Organization or Project. {% endhint %} To change an existing teammate's role, ask someone who can edit teammates directly. Requests can't change roles. #### What approving does * **New person or contact:** they're added to the Organization or Project and sent an invitation email. * **Existing active teammate:** they're added, with no new invitation. * **Removal:** they leave that Organization or Project only. Removing from an Organization also removes them from its Projects. Their account and other access stay the same. * **If the invitation email fails,** the approval still stands. Resend it with **Invite User** on the contact. #### Other rules * Only one pending request per person, scope, and type. A duplicate is refused with a clear message. * The first decision wins. Other approvers see who decided, and their notifications clear automatically. * Only the requester can cancel their request. Approvers reject instead. * You can't request your own removal. * Notifications are in-app only. Approvers don't get email for new requests. ### FAQ
I don't see Request Access. Why? Either you can already invite people there (you'll see **Invite User** instead), or your role doesn't include the Request Access permission. Ask your administrator.
The role picker says "The reviewer will choose the role." Is something wrong? No. No role could be offered for that person, usually because no available role fits their email domain (for example, an outside email when the Account has no client roles). Send the request as normal, and the approver will pick a role.
Why can't I pick an internal role for someone? Their email isn't on your company's internal domains, so they can only receive client (External) roles.
Who gets notified about my request? Everyone who can approve requests for that Organization or Project.
How do I know when my request is decided? You get an Inbox notification saying whether it was approved or rejected, with any note from the approver.
Can I change a request after sending it? Not yet. Cancel it and raise a new one.
Two approvers clicked Approve at the same time. What happens? The change is applied once. The second approver sees that the request was already decided.
Does removing someone delete their account? No. It removes them from that Organization or Project only.
Will approvers get an email? Not today. Notifications appear in the Transform Inbox and on the Access Requests list.
### Summary * Requesters raise access and removal requests from **Teammates**. * Approvers decide from the Inbox or **Access Requests**. * Approving applies the change with the same checks as a direct invite or removal. Related: * [Add Teammates](/organizations-and-projects/add-teammates) * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # User Roles and Permissions Understand roles, permissions, and how they apply at Account, Organization, and Project scope. ### Overview Roles define what actions are permitted within a scope. Scopes define what content is visible. Use [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) to pick scope first. ### Key Concepts * **Scope**: Account, Organization, Project visibility boundary * **Role**: permission set within a scope * **Mixed membership**: different roles for the same Teammate at different scopes ### How It’s Used Use roles to separate governance actions from delivery actions. Assign roles per scope to match the delivery model. ### Benefits * Fewer permission mistakes * Reduced risk from over-scoped access * Cleaner governance through predictable ownership ### Setup Steps * **Account Administrator**: Full administrative control across the Account. Manage Teammates, roles, billing, custom fields, and global settings. * **Project Manager**: Manage work at Project scope. Create and update Projects, assign tasks, manage timelines, configure workflows, and invite Teammates to specific Projects. No Account-wide admin access. * **Consultant**: Contribute to delivery work without sensitive admin access. Edit entities, such as requirements and solutions, and collaborate inside assigned Projects. * **Client Collaborator**: Support shared delivery with limited access. View and make limited edits to shared Projects, Artifacts, and discussions without broader internal access. * **Client Tester**: Focus on testing activity. View test cases, execute tests, and provide feedback without changing core Project structure. * **Owner**: Hold broad control within the assigned scope, such as a Project or Organization. Edit, delete, assign, and manage work in that scope. * **Member**: Handle day-to-day delivery work. Create, edit, and view assigned Projects, tasks, and entities without managing Teammates or structural settings. * **Viewer**: Review work in read-only mode. View Projects, reports, dashboards, and entity details without creating or editing content. #### Current roles Start with scope first. Then assign the narrowest role that supports the work. * **Account Administrator**: global permission to everything. Cannot be archived, hidden, or deleted. Applies across all Organizations and all Projects. * **Managing Partner**: global permission to everything. Applies across all Organizations and all Projects, including external access. * **Project Manager**: Project administration scoped to assigned Organizations. Applies across all Projects within those Organizations. * **Consultant**: full permissions scoped to assigned Organizations. Applies across all Projects within those Organizations. * **Client Collaborator**: edit access on assigned Organizations and Projects. Enable **External** when assigning this role. * **Client Tester**: edit access on Test Cases only. View-only on everything else. Enable **External** when assigning this role. * **View Only**: read-only access wherever explicitly added. No Organization-wide or Project-wide access by default. {% hint style="warning" %} The **External** toggle distinguishes client-facing roles from internal roles. Enable it for **Client Collaborator** and **Client Tester**, and for any Teammate who is a client or external user. {% endhint %} #### Common permission boundaries Use this as a decision check: * Manage Account-wide access and settings → Account Administrator * Manage Project delivery, assignments, and workflows → Project Manager or Owner * Create and update delivery work → Consultant or Member * Review shared work or execute tests with limited edit rights → Client Collaborator or Client Tester * Review and approve without edits → Viewer * Global administration across the account → **Account Administrator** or **Managing Partner** * Project administration across assigned Organizations → **Project Manager** * Delivery work across assigned Organizations → **Consultant** * Client-facing editing in assigned areas → **Client Collaborator** * Client-facing test execution with limited edit rights → **Client Tester** * Read-only participation → **View Only** ### Best Practices * Keep **Account Administrator** and **Managing Partner** access limited. * Enable **External** for all client-facing Teammates. * Use **View Only** for stakeholders who only need visibility. * Avoid role sprawl by standardizing role definitions in an internal SOP. ### Summary Roles define permitted actions within a scope. Select scope first. Then assign the least-privilege role. Related: * [Add Teammates](/organizations-and-projects/add-teammates) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) # Team Management Invite Teammates, assign roles by scope, and keep access aligned to delivery needs. ### Overview Team Management controls who can access Transform. It also controls what actions are permitted. Access is scoped to Account, Organization, and Project. ### Key Concepts * **Teammate**: person record with access at one or more scopes * **Scope**: what a Teammate can see (Account, Organization, Project) * **Role**: what a Teammate can do within a scope * **Least privilege**: grant only the access required for delivery work ### How It’s Used Use this section during onboarding and governance changes. Use it for regular access reviews and offboarding. ### Benefits * Reduced risk from over-scoped access * Cleaner collaboration through consistent role assignment * Easier audits through predictable access patterns ### Setup Steps {% stepper %} {% step %} ### Define access scope Start by picking scope, then assign a role. * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) {% endstep %} {% step %} ### Invite or update Teammates * [Add Teammates](/organizations-and-projects/add-teammates) {% endstep %} {% step %} ### Standardize roles and permissions * [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions) {% endstep %} {% endstepper %} ### Best Practices * Limit Account Admin and Owner roles to a small set. * Prefer Project scope for external collaborators. * Review access monthly and after major delivery milestones. ### Summary Team Management is the control plane for access and collaboration. Scope controls visibility. Roles control actions. # Projects Use Projects to manage one transformation initiative end-to-end. ### Overview Projects are delivery containers inside an Organization. They hold the work needed to deliver one initiative. ### Key Concepts * **Project scope**: requirements, tasks, tests, artifacts, and settings for delivery work * **Project configuration**: defaults, fields, and roles that shape day-to-day workflows * **Project sections**: grouping mechanism for phases, sprints, and workstreams ### How It’s Used Create a Project per initiative, such as an ERP implementation phase or a process redesign effort. Use Projects to track scope (requirements), execution (tasks), and validation (testing). ### Benefits * Clean separation of initiatives within an Organization * Repeatable governance through templates and settings * Better reporting and review through consistent configuration ### Setup Steps {% stepper %} {% step %} ### Create a Project * [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Configure Project settings * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) {% endstep %} {% step %} ### Define Project sections (optional) * [Project Sections](/organizations-and-projects/project-sections) {% endstep %} {% endstepper %} ### Best Practices * Establish naming conventions before creating many Projects. * Configure custom fields before importing large volumes of work items. * Keep shared settings stable and review changes quarterly. ### Summary Projects hold delivery work for one initiative. Project settings and sections standardize execution and reporting. Related: * [Organizations](/organizations-and-projects/organizations) * [Understanding Organizations and Projects](/organizations-and-projects/understanding-organizations-and-projects) * [Create a Project](/getting-started/create-a-project) # Understanding Organizations and Projects Learn how Organizations and Projects structure delivery work and access scope. ### Overview Organizations and Projects define how work is structured in Transform. This structure also defines the scope for access control and reporting. ### Key Concepts #### Organization An Organization is a container for work belonging to a client, department, or business unit. Organizations contain Projects. #### Project A Project is a delivery container for a single transformation initiative. Projects contain requirements, tasks, tests, and artifacts. #### Access scope Access is assigned at Account, Organization, and Project scope. Scope determines what a Teammate can see. * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) ### How It’s Used Use Organizations to separate clients or internal divisions. Use Projects to separate initiatives and delivery timelines. ### Benefits * Clear separation of work by client or department * Cleaner access control through scope-based permissions * More consistent reporting across Projects ### Setup Steps Follow the common setup path. {% stepper %} {% step %} ### Create an Organization Create an Organization for a client, department, or business unit. * [Create an Organization](/organizations-and-projects/create-an-organization) {% endstep %} {% step %} ### Create a Project Create a Project for one transformation initiative. * [Create a Project](/getting-started/create-a-project) {% endstep %} {% step %} ### Configure the project Set defaults, roles, fields, and integrations. * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) {% endstep %} {% endstepper %} ### Best Practices * Keep Organization names stable. * Use consistent Project naming, such as `{Organization} {initiative}`. * Start with least-privilege access and expand only when needed. ### Summary Core pages: * [Organizations](/organizations-and-projects/organizations) * [Projects](/organizations-and-projects/projects) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) Related: * [Start Here](/getting-started/start-here) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) # Blueprint Fundamentals Build reusable structure for Projects using processes, systems, and segmentation. ### Overview Blueprints define reusable structure for delivery work. They reduce setup time and improve consistency across Projects. ### Key Concepts * **Blueprint**: reusable structure applied to new Projects * **Process**: business workflow, phase, or workstream tracked in a Blueprint * **System**: application or platform linked to Processes * **Segmentation**: Segment Types and Segments used for scoping and reporting ### How It’s Used Create a Blueprint for a repeatable delivery method. Reuse the Blueprint to create multiple Projects with consistent structure. ### Benefits * Faster Project setup with fewer early decisions * Consistent naming, hierarchy, and reporting fields * Cleaner governance through standard structures ### Setup Steps {% stepper %} {% step %} ### Create a Blueprint * [Creating Blueprints](/blueprints/creating-blueprints) {% endstep %} {% step %} ### Define Processes * [Processes](/blueprints/creating-blueprints/processes) * [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) {% endstep %} {% step %} ### Define Systems * [Create Systems](/blueprints/systems-management/create-systems) * [System Types](/blueprints/systems-management/system-types) {% endstep %} {% step %} ### Define segmentation (optional) * [Segmentation](/blueprints/segmentation) {% endstep %} {% endstepper %} ### Best Practices * Start with a small set of Processes and expand over time. * Keep hierarchies shallow to improve navigation and reporting. * Avoid client-specific names in reusable Blueprints. ### Summary Blueprints standardize delivery structure across Projects. Processes, Systems, and Segmentation provide core building blocks. Related: * [What Are Blueprints?](/blueprints/blueprint-fundamentals/what-are-blueprints) * [Create a Project](/getting-started/create-a-project) # What Are Blueprints? Understand why Blueprints exist and how they standardize delivery structure across Projects. ### Overview Blueprints define reusable structure for Project delivery work. They standardize naming, hierarchy, and reporting fields. ### Key Concepts * **Blueprint**: reusable structure applied to new Projects * **Process**: business workflow, phase, or workstream tracked in a Blueprint * **System**: application or platform linked to Processes * **Hierarchy**: parent-child structure used for rollups ### How It’s Used Create one Blueprint per delivery method. For example: an ERP implementation approach. Reuse the Blueprint to create multiple Projects with consistent structure. ### Benefits * Faster Project creation with fewer setup decisions * More consistent reporting across Projects * Cleaner governance through standardized structure ### Setup Steps 1. Create a Blueprint. 2. Define Processes and hierarchy. 3. Add Systems and System Types. 4. Define segmentation when reporting requires it. ### Best Practices * Keep Blueprints reusable and avoid client-specific naming. * Use hierarchy for rollups, not for single tasks. * Document naming conventions in an internal SOP. ### Summary Blueprints are reusable templates for Projects. They define Processes, Systems, and hierarchy for consistent execution. Related: * [Blueprint Fundamentals](/blueprints/blueprint-fundamentals) * [Creating Blueprints](/blueprints/creating-blueprints) * [Processes](/blueprints/creating-blueprints/processes) * [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) # Creating Blueprints Create a Blueprint and define the reusable structure for new Projects. ### Overview Creating a Blueprint establishes reusable delivery structure. Blueprints are typically created before creating many Projects. ### Key Concepts * **Blueprint scope**: reusable structure for future Projects * **Processes and Systems**: primary structure used for traceability and reporting * **Segmentation**: optional Organization-level structure for consistent reporting ### How It’s Used Use this workflow during initial rollout. Use it again when a new delivery method is introduced. ### Benefits * Faster onboarding for new Projects * More consistent naming and reporting across initiatives * Reduced rework from inconsistent structure ### Setup Steps {% stepper %} {% step %} ### Create the Blueprint 1. Navigate to **Blueprints**. 2. Select **New Blueprint**. 3. Set the name and description. Use a stable naming pattern, such as `{method} Blueprint`. {% endstep %} {% step %} ### Define Processes Define Processes to represent workflows, phases, or workstreams. * [Processes](/blueprints/creating-blueprints/processes) * [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) {% endstep %} {% step %} ### Add Systems Add Systems that support delivery scope. * [Create Systems](/blueprints/systems-management/create-systems) * [System Types](/blueprints/systems-management/system-types) {% endstep %} {% step %} ### Define segmentation (optional) Define Segment Types and Segments when reporting needs consistent structure. * [Segmentation](/blueprints/segmentation) {% endstep %} {% endstepper %} ### Best Practices * Keep the first Blueprint minimal and expand after use. * Standardize naming before creating many Processes and Systems. * Treat Blueprint changes as governed updates. ### Summary Creating a Blueprint establishes reusable structure for Projects. Processes and Systems are the primary building blocks. # Processes Set up a reusable process map for a Blueprint. ### Overview Processes are the primary structure inside a Blueprint. They model workflows, phases, and workstreams for delivery tracking. ### Key Concepts * **Process**: reusable workflow, phase, or workstream * **Hierarchy**: parent-child rollups for navigation and reporting * **Linking**: relationships to Systems and Segments for traceability ### How It’s Used Use Processes to group Requirements and Tasks by business flow. Use hierarchy for rollups in reporting and reviews. Processes defined in a Blueprint can be included in new Projects. Some UI labels may refer to Projects as Transformations. ### Benefits * Consistent structure across Projects * Cleaner reporting by workflow and ownership * Faster navigation for delivery teams ### Setup Steps {% stepper %} {% step %} ### Create a process 1. Navigate to **Blueprints**. 2. Open a Blueprint. 3. Open **Processes**. 4. Select **Add process**. Define: * **Name** * Optional fields when enabled, such as Code, Owner, and Description {% endstep %} {% step %} ### Build hierarchy (optional) Create parent processes for rollups. Add child processes that represent real subsets. See [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy). {% endstep %} {% step %} ### Link to Systems and Segments (optional) Link processes to Systems to clarify technology scope. Link processes to Segments to support reporting by business dimension. * [Create Systems](/blueprints/systems-management/create-systems) * [Segmentation](/blueprints/segmentation) {% endstep %} {% endstepper %} ### Best Practices * Use one naming pattern across Blueprints. * Keep hierarchies to 2–3 levels for most teams. * Avoid creating processes for single tasks. ### Summary Processes define the Blueprint structure used for delivery tracking. Hierarchy and linking improve navigation and reporting. Related: * [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) * [Create Systems](/blueprints/systems-management/create-systems) * [Systems Management](/blueprints/systems-management) * [Segmentation](/blueprints/segmentation) # Process Hierarchy Model rollups with parent-child processes for navigation and reporting. ### Overview Process hierarchy models rollups inside a Blueprint. It supports navigation and reporting without creating extra fields. ### Key Concepts * **Parent process**: grouping node used for rollups * **Child process**: real subset of a parent process * **Hierarchy depth**: number of parent-child levels ### How It’s Used Use hierarchy when teams need both summary and detail reporting. Use it to model phases, business areas, or workstreams. ### Benefits * Cleaner reporting and rollups * Faster navigation in large Process maps * More consistent structure across Projects ### Setup Steps {% stepper %} {% step %} ### Create a parent process Create a top-level grouping node such as `Finance` or `Implementation`. {% endstep %} {% step %} ### Add child processes Add child processes that represent real subsets of the parent. {% endstep %} {% step %} ### Keep depth shallow Prefer 2–3 levels for most Blueprints. {% endstep %} {% endstepper %} ### Best Practices * Use parent nodes as categories, not deliverables. * Avoid deep trees that create reporting friction. * Keep naming consistent across Blueprints. ### Summary Process hierarchy enables rollups for navigation and reporting. Parent-child structure should stay shallow and consistent. Related: * [Processes](/blueprints/creating-blueprints/processes) # Systems Management Define Systems and System Types in a Blueprint, then link Systems to Processes. ### Overview Systems represent applications and platforms in scope for delivery work. Linking Systems to Processes supports traceability and reporting. ### Key Concepts * **System**: application, platform, or service in scope * **System Type**: classification used for filtering and reporting * **Environment**: production, test, or sandbox context for a System record ### How It’s Used Use Systems to document scope and ownership. Use System Types to standardize reporting across Projects. ### Benefits * Clearer scope definition across delivery teams * Better reporting through consistent system classification * Faster impact analysis when changes affect multiple Processes ### Setup Steps {% stepper %} {% step %} ### Create Systems * [Create Systems](/blueprints/systems-management/create-systems) {% endstep %} {% step %} ### Define System Types * [System Types](/blueprints/systems-management/system-types) {% endstep %} {% step %} ### Link Systems to Processes Link Systems to Processes for traceability. {% endstep %} {% endstepper %} ### Best Practices * Create separate System records for separate environments. * Standardize System Type names across Blueprints. * Keep System names stable and human-searchable. ### Summary Systems Management defines the technology scope for a Blueprint. System Types and process links support reporting and traceability. # Create Systems Add Systems to a Blueprint, then link Systems to Processes for traceability. ### Overview Systems represent applications and platforms in scope for delivery work. Linking Systems to Processes supports traceability and reporting. ### Key Concepts * **System**: application, platform, or service in scope * **System Type**: classification used for filtering and reporting * **Environment**: production, test, or sandbox context for a System record ### How It’s Used Use Systems to define technology scope alongside Processes. Use System Types to standardize reporting across Projects. ### Benefits * Clearer technology scope for delivery teams * Better reporting through consistent classification * Faster impact analysis through links to Processes ### Setup Steps {% stepper %} {% step %} ### Add a System to a Blueprint 1. Navigate to **Blueprints**. 2. Open a Blueprint. 3. Open **Systems** (or **Systems Management**). 4. Select **Add system**. {% endstep %} {% step %} ### Define core fields Required: * **Name**: stable internal name, such as `ERP — Production` Optional fields when enabled: * **System Type**: such as `ERP`, `CRM`, `Data`, `Integration` * **Environment**: Production, Sandbox, UAT, Dev * **Owner / Admin** * **URL / login** * **Description** {% endstep %} {% step %} ### Link Systems to Processes Linking is many-to-many. One Process can run on several Systems. For example: * `Procure-to-Pay` → `ERP — Production` * `Customer lifecycle` → `CRM — Production` * `Data integration` → `Integration platform` {% endstep %} {% endstepper %} ### Best Practices * Create separate System records for separate environments. * Keep System Types small and stable. * Avoid generic System names without environment context. ### Summary Systems define technology scope for a Blueprint. Links to Processes support traceability and reporting. #### Troubleshooting
System cannot be linked to a process Confirm both items are active. Confirm Blueprint edit permission exists.
System does not appear in a Project Confirm the System exists in the Blueprint. Confirm the Project was created after the System was added.
Related: * [What Are Blueprints?](/blueprints/blueprint-fundamentals/what-are-blueprints) * [Processes](/blueprints/creating-blueprints/processes) * [Process Hierarchy](/blueprints/creating-blueprints/process-hierarchy) * [Systems Management](/blueprints/systems-management) * [System Types](/blueprints/systems-management/system-types) # System Types Classify Systems for filtering, reporting, and consistent governance. ### Overview System Types classify Systems into meaningful groups. This supports consistent filtering and reporting across Projects. ### Key Concepts * **System Type**: reusable classification for Systems * **Reporting consistency**: standard types reduce one-off naming ### How It’s Used Use System Types to group Systems by function. Use types in views, exports, and reporting workflows. ### Benefits * Cleaner reporting across Projects * Faster filtering in large System lists * More consistent governance and ownership reviews ### Setup Steps {% stepper %} {% step %} ### Define System Types Create a small set of stable types. For example: `ERP`, `CRM`, `Data`, `Integration`, and `Payments`. {% endstep %} {% step %} ### Assign types to Systems Update Systems to include the correct System Type. {% endstep %} {% endstepper %} ### Best Practices * Keep the list small and stable. * Avoid overlapping types that create ambiguous reporting. * Document type meanings in an internal SOP. ### Summary System Types standardize classification for Systems. They support filtering and reporting across Projects. # Segmentation Model Organization structure with Segment Types and Segments for scoping and reporting. ### Overview Segments model Organization structure for scoping and reporting. Segments are not tags or project labels. Segments and Segment Types are scoped to the **Organization**. ### Key Concepts #### Segment Types A Segment Type defines a business dimension. Pick dimensions used to operate the Organization. For example: * Legal Entity * Department * Line of Business * Business Unit * Region #### Segments Segments are values inside a Segment Type. They represent divisions used for ownership and reporting. For example, under **Region**: * North America * EMEA * APAC Segments can be hierarchical. For example: `North America` → `United States` → `Northeast`. ### How It’s Used Use Segments to scope work to a part of the Organization. Use Segments to filter and group reporting views. Segments can be applied across multiple entity types: * **Processes**: map process ownership by Organization unit. * **Systems**: align systems to a legal entity or department. * **RACI items**: define accountability within an Organization boundary. * **Requirements**: scope and filter by the business unit impacted. ### Benefits Consistent segmentation enables: * Filter requirements, tasks, and processes by Organization dimension. * Group work by legal entity, department, or line of business. * Build scoped views for a specific part of the business. * Align accountability and governance to Organization boundaries. ### Setup Steps {% stepper %} {% step %} ### Create a Segment Type Define the business dimension to track. 1. Open the Organization. 2. Create a Segment Type (for example: `Department`). {% endstep %} {% step %} ### Create Segments Add the actual values for that dimension. Create Segments inside the Segment Type. Optionally assign a parent Segment to build a hierarchy. {% endstep %} {% step %} ### Apply segments to work Associate Segments with processes, systems, RACI items, and requirements. Use Segments for filtering, sorting, and reporting. {% endstep %} {% endstepper %} ### Best Practices {% hint style="info" %} **Ground segments in the real org structure.** If a value would not show up on an organization chart, it is usually not a Segment. {% endhint %} {% hint style="info" %} **Use hierarchies when you need rollups.** Parent-child segments enable both summary and deep reporting. {% endhint %} {% hint style="success" %} **Be consistent across entity types.** The value comes from reuse, not one-off assignments. {% endhint %} {% hint style="warning" %} **Avoid Segment Type sprawl.** Start with a few strong dimensions. Add more only when reporting needs require it. {% endhint %} ### Summary Segmentation standardizes business structure for scoping and reporting. Segment Types define dimensions. Segments provide values and optional hierarchy. #### Quick decision check If unsure whether something is a Segment Type: * Does this reflect how the Organization operates? * Would it appear in a formal business taxonomy? * Is it a real division, not a project category? If yes, this is usually a good fit. Related: * [Organizations](/organizations-and-projects/organizations) * [Organization Settings and Management](/organizations-and-projects/organization-settings-and-management) * [What Are Blueprints?](/blueprints/blueprint-fundamentals/what-are-blueprints) # Requirements Turn discovery inputs into structured, reviewable scope with traceability to tasks and tests. ### Overview Requirements represent scope that must be delivered and validated. They connect discovery inputs to tasks and test cases. ### Key Concepts * **Requirement**: scope statement with acceptance criteria * **Lifecycle**: statuses that move scope from draft to completed * **Traceability**: links from requirements to tasks and tests ### How It’s Used Use Requirements to define what must be delivered. Use tasks to implement requirements. Use tests to validate requirements. ### Benefits * Clearer scope boundaries and reduced scope creep * Better accountability through ownership and status tracking * Stronger audits through traceability to validation evidence ### Setup Steps {% stepper %} {% step %} ### Create a requirement 1. Navigate to a Project. 2. Open **Requirements**. 3. Select **New requirement**. 4. Define title, description, and acceptance criteria. {% endstep %} {% step %} ### Use consistent lifecycle states Typical states include Draft, In review, Approved, In progress, and Completed. Status names vary by Account configuration. {% endstep %} {% step %} ### Link to tasks and tests Link requirements to tasks for execution tracking. Link requirements to tests for coverage tracking. * [Create and Assign Tasks](/transformations/create-and-assign-tasks) * [Create Test Cases](/transformations/create-test-cases) {% endstep %} {% endstepper %} {% hint style="info" %} When enabled, Console can generate draft tasks and draft test cases from requirement context. Generated output still requires review before approval. {% endhint %} ### Best Practices * Require acceptance criteria before approval. * Keep requirement titles short and scannable. * Link artifacts that justify scope decisions. * Use Segments and Processes for reporting consistency when configured. ### Summary Requirements define scope and connect to execution and validation. Traceability links support reporting, governance, and audits. ### Related * [Requirements Management](/transformations/requirements-management) * [Requirements View](/transformations/requirements-view) * [Requirements Modification](/transformations/requirements-modification) * [Requirements Rejection](/transformations/requirements-rejection) * [Audit Trail](/transformations/audit-trail) * [Dependencies and Relationships](/transformations/dependencies-and-relationships) * [Creating Dependencies Between Requirements](/transformations/creating-dependencies-between-requirements) * [Custom Fields](/administration/custom-fields) * [Working with Views](/getting-started/working-with-views) # Audit Trail ### Overview Audit Trail records what changed, when, and by whom. It supports compliance, governance, and delivery accountability. ### Key Concepts * **Event**: a recorded change, such as a field update * **Actor**: the Teammate or system process that made the change * **Timestamp**: time the event was recorded * **Context**: linked item details, such as a requirement or task ### How It’s Used Use Audit Trail during approval reviews. Use it to resolve “what changed?” questions quickly. ### Benefits * Clear accountability for scope and status changes * Faster investigations during delivery issues * Stronger evidence for compliance audits ### Setup Steps {% stepper %} {% step %} ### Open an item 1. Open a requirement, task, or test case. 2. Locate the history or activity area. {% endstep %} {% step %} ### Review change history 1. Scan for status, owner, and date changes. 2. Open details for high-impact events. {% endstep %} {% step %} ### Capture evidence (optional) 1. Copy event details into an Artifact when required. 2. Include links back to the source item. {% endstep %} {% endstepper %} ### Best Practices * Record rationale in comments when changing scope or approvals. * Keep approvals inside the work item, not external threads. * Use consistent statuses to reduce ambiguous history. ### Summary Audit Trail is the source of truth for change history. Pair it with structured requirements and statuses for clean governance. # Creating Dependencies Between Requirements ### Overview Requirement dependencies capture sequencing across scope statements. They prevent downstream work from starting too early. ### Key Concepts * **Upstream requirement**: prerequisite scope * **Downstream requirement**: dependent scope * **Blocks / Blocked by**: sequencing relationship used for planning ### How It’s Used Use dependencies during discovery and design sequencing. Use them to communicate prerequisite decisions. ### Benefits * Cleaner sequencing and planning * Earlier identification of blocker risk * Clearer discussion during governance reviews ### Setup Steps {% stepper %} {% step %} ### Open the requirement 1. Navigate to **Requirements**. 2. Open the downstream requirement. {% endstep %} {% step %} ### Add a dependency 1. Locate the **Dependencies** area. 2. Select **Add dependency**. 3. Choose the upstream requirement. 4. Select relationship type, such as **Blocked by**. {% endstep %} {% step %} ### Confirm the relationship 1. Confirm the dependency appears on both requirements. 2. Add a comment describing the unblock condition. {% endstep %} {% endstepper %} ### Best Practices * Keep dependencies minimal and meaningful. * Use comments to document why the dependency exists. * Review dependencies during requirement approval. ### Summary Dependencies encode prerequisite scope. They also reduce rework caused by premature execution. # Viewing Dependency Chains ### Overview Dependency chains show upstream blockers and downstream impact. They support critical path reviews. ### Key Concepts * **Chain**: ordered set of dependencies * **Critical path signal**: small set of dependencies driving schedule risk * **Impact**: downstream items affected by an upstream delay ### How It’s Used Use dependency chains during planning and status reviews. Use them when triaging blocker risk. ### Benefits * Faster identification of root blockers * Clearer sequencing discussions * Better prioritization of unblock work ### Setup Steps {% stepper %} {% step %} ### Open the dependency view 1. Open a requirement or task with dependencies. 2. Open the dependency chain view, graph, or panel. {% endstep %} {% step %} ### Traverse upstream and downstream 1. Review upstream items first. 2. Identify the earliest unresolved blocker. 3. Review downstream items impacted by that blocker. {% endstep %} {% step %} ### Capture decisions 1. Record sequencing decisions in comments. 2. Update dependencies when sequencing changes. {% endstep %} {% endstepper %} ### Best Practices * Keep chains short by removing weak relationships. * Avoid using dependencies as general associations. * Review chains during weekly governance. ### Summary Dependency chains make sequencing visible. They also provide a shared reference for blocker triage. # Managing Blocked Items ### Overview Blocked items represent work that cannot progress. They require explicit unblock ownership and sequencing decisions. ### Key Concepts * **Blocked status**: explicit signal that work cannot proceed * **Unblock condition**: what must happen to resume work * **Owner**: Teammate accountable for progressing the item ### How It’s Used Use blocked-item reviews during governance meetings. Use them during daily execution triage. ### Benefits * Faster escalation of risk * Cleaner communication across teams * Less hidden idle time in delivery plans ### Setup Steps {% stepper %} {% step %} ### Identify blocked work 1. Open **Requirements** or **Tasks**. 2. Filter for `Status = Blocked` (or equivalent field). 3. Save the view as a Save View for repeatable reviews. {% endstep %} {% step %} ### Record unblock conditions 1. Open each blocked item. 2. Add a comment stating the unblock condition. 3. Add the accountable owner in the comment. {% endstep %} {% step %} ### Clear blocked signals 1. Update dependencies when prerequisites are completed. 2. Update status from **Blocked** to the next valid status. 3. Record the reason for the change in a comment. {% endstep %} {% endstepper %} ### Best Practices * Keep Blocked as a high-signal status. * Require an unblock condition on every blocked item. * Review blocked work at least weekly. ### Summary Blocked items should be visible and managed actively. Save Views keep the blocked review repeatable. # Dependencies and Relationships ### Overview Dependencies encode sequencing across requirements and tasks. They expose blockers early and protect delivery planning. ### Key Concepts * **Blocks / Blocked by**: sequencing relationship * **Related**: association without sequencing intent * **Dependency chain**: multi-hop set of dependencies * **Blocked item**: item that cannot progress due to a dependency ### How It’s Used Use dependencies during planning and execution. Use them for “blocked work” triage during weekly reviews. ### Benefits * Clear sequencing for delivery work * Earlier visibility into blocker risk * Cleaner reporting for critical path work ### Setup Steps {% stepper %} {% step %} ### Create a dependency Create a dependency from an item detail view. Related: [Creating Dependencies Between Requirements](/transformations/creating-dependencies-between-requirements) {% endstep %} {% step %} ### Review dependency chains Review upstream blockers and downstream impacts. Related: [Viewing Dependency Chains](/transformations/viewing-dependency-chains) {% endstep %} {% step %} ### Manage blocked items Create a repeatable blocked-items view for governance reviews. Related: [Managing Blocked Items](/transformations/managing-blocked-items) {% endstep %} {% endstepper %} ### Best Practices * Prefer dependencies for true sequencing constraints. * Avoid circular dependencies. * Record unblock conditions in comments. ### Summary Dependencies make planning explicit. They also create a shared language for blockers and sequencing. # Requirements View Review requirements with consistent columns, filters, and Save Views. ### Overview Requirements View is the primary list view for reviewing scope. A stable view reduces review churn and improves reporting consistency. ### Key Concepts * **Save View**: stored configuration for repeatable review lists * **Columns**: fields used for triage and reporting * **Filters and grouping**: focus reviews by status, owner, process, or segment ### How It’s Used Use a default Requirements View for weekly scope reviews. Use dedicated Save Views for approval, change control, and delivery readiness. ### Benefits * Faster triage during scope reviews * More consistent reporting across Projects * Reduced rework from inconsistent filtering ### Setup Steps {% stepper %} {% step %} ### Open Requirements Navigate to a Project. Open **Requirements**. {% endstep %} {% step %} ### Configure columns Show fields used for scope reviews. Typical fields include Status, Owner, Process, Priority, and Due date. {% endstep %} {% step %} ### Create Save Views Create Save Views for repeatable reviews, such as `Requirements — In review` and `Requirements — Approved`. {% endstep %} {% endstepper %} ### Best Practices * Keep shared Save Views stable. * Duplicate shared views before major changes. * Use consistent naming patterns across Projects. ### Summary Requirements View standardizes how scope is reviewed. Save Views provide repeatable review lists. Related: * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) * [Save Views and Templates](/getting-started/save-views-and-templates) # Requirements Modification Update requirements while preserving change history and approval intent. ### Overview Requirements change as discovery and design progress. A controlled modification approach preserves context and auditability. ### Key Concepts * **Change intent**: why a requirement is changing ### How It’s Used Use modification when scope changes or wording needs clarification. Use it to update acceptance criteria and linked artifacts. ### Benefits * Reduced rework through clear change communication * Better auditability through explicit change history * Faster impact analysis across linked work ### Setup Steps {% stepper %} {% step %} ### Locate the requirement Open **Requirements**. Find the requirement using Global Search or filters. {% endstep %} {% step %} ### Update the requirement Update title, description, and fields. Update acceptance criteria when the expected outcome changes. {% endstep %} {% step %} ### Validate links Review linked tasks, tests, and artifacts. Update links when scope boundaries changed. {% endstep %} {% step %} ### Move back into review Set status to an in-review state when approvals are required. {% endstep %} {% endstepper %} ### Best Practices * Capture rationale in comments for high-impact changes. * Avoid changing meaning without updating acceptance criteria. * Re-run testing coverage checks after major changes. ### Summary Requirements Modification supports controlled scope change. Links and review status keep delivery work aligned. Related: * [Requirements](/transformations/requirements) * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) # Requirements Rejection Use rejection states to prevent delivery work on out-of-scope requirements. ### Overview Not all requirements should be delivered. A clear rejection workflow prevents work on out-of-scope items. ### Key Concepts * **Rejection reason**: why the requirement is not being delivered * **Status semantics**: difference between rejected, deferred, and obsolete * **Downstream impact**: tasks and tests that must be closed or updated ### How It’s Used Use rejection when scope is explicitly removed. Use deferral when scope remains valid but not in the current phase. ### Benefits * Reduced wasted effort * Clearer audit trail for scope decisions * Cleaner reporting by excluding non-deliverable scope ### Setup Steps {% stepper %} {% step %} ### Confirm decision Record decision rationale in comments. Link supporting artifacts when available. {% endstep %} {% step %} ### Set requirement status Set status to a rejected or out-of-scope state. Use standardized status meanings across Projects. {% endstep %} {% step %} ### Close downstream work Close or re-scope linked tasks and tests. Remove assignments that would continue delivery work. {% endstep %} {% endstepper %} ### Best Practices * Avoid deleting rejected requirements. * Prefer clear status states for reporting. * Use a consistent set of rejection reasons in an internal SOP. ### Summary Requirements Rejection prevents delivery work on removed scope. Status and downstream cleanup keep reporting accurate. Related: * [Requirements](/transformations/requirements) * [Status Types and Meanings](/transformations/status-types-and-meanings) # Requirements Management Define requirement lifecycle, review states, and traceability practices. ### Overview Requirements Management controls how scope is captured, reviewed, changed, and reported. A consistent lifecycle reduces rework and improves auditability. ### Key Concepts * **Lifecycle**: status and review stages for requirements * **Acceptance criteria**: objective conditions for validation * **Traceability**: links to tasks, tests, and artifacts * **Change control**: modification and rejection patterns that preserve context ### How It’s Used Use this structure for weekly scope reviews. Use it for approval workflows and change control. ### Benefits * Reduced rework from unclear scope * Cleaner approvals through standardized review states * Faster impact analysis through traceability ### Setup Steps {% stepper %} {% step %} ### Define statuses and meanings Standardize requirement statuses across Projects. Use a small set of review states for approvals. {% endstep %} {% step %} ### Standardize review views Create shared Save Views for repeatable scope reviews. * [Requirements View](/transformations/requirements-view) {% endstep %} {% step %} ### Define modification and rejection patterns Use controlled change patterns to preserve context and downstream alignment. * [Requirements Modification](/transformations/requirements-modification) * [Requirements Rejection](/transformations/requirements-rejection) {% endstep %} {% endstepper %} ### Best Practices * Require acceptance criteria for approval-ready requirements. * Link tasks and tests to requirements early. * Use Segments and Processes for reporting consistency. ### Summary Requirements Management standardizes scope lifecycle and change control. Save Views and traceability support repeatable review and governance. Related: * [Requirements](/transformations/requirements) * [Create and Assign Tasks](/transformations/create-and-assign-tasks) * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) # Create and Assign Tasks Turn requirements and action items into owned, trackable work. ### Overview Tasks turn approved scope into owned execution work. They create accountability and progress tracking at the work-item level. ### Key Concepts * **Task**: unit of delivery work with an owner and status * **Assignee**: single Teammate accountable for completion * **Linked requirement**: scope traceability from task to requirement * **Due date**: scheduling signal for planning and escalation * **Dependency**: sequencing constraint across tasks ### How It’s Used Create tasks during planning. Update tasks during daily execution and weekly reviews. ### Benefits * Clear ownership for execution work * Cleaner progress reporting * Better traceability from requirements to delivery evidence ### Setup Steps {% stepper %} {% step %} ### Create a task from the Tasks area 1. Open the Project. 2. Navigate to **Tasks**. 3. Select **Create task** (or **New task**). 4. Enter a short, verb-based task name. 5. Select **Create** (or **Save**). {% endstep %} {% step %} ### Create a task from a requirement (recommended) 1. Navigate to **Requirements**. 2. Open a requirement. 3. Select **Create task** (or equivalent action). 4. Confirm the requirement link is created. {% endstep %} {% step %} ### Assign an owner and set intent 1. Set **Assignee** to one Teammate. 2. Set **Status** to the correct starting state. 3. Set a **Due date** when sequencing requires it. 4. Add acceptance criteria in the description when needed. {% endstep %} {% step %} ### Organize execution (optional) 1. Add subtasks for multi-step work. 2. Add dependencies for true sequencing constraints. Related: [Task Dependencies](/transformations/task-dependencies) {% endstep %} {% endstepper %} ### Best Practices * Keep one assignee per task. * Keep tasks small enough for weekly reporting. * Link tasks to requirements for traceability. * Use **Blocked** only with an unblock condition. * Record decisions and changes in comments for auditability. ### Summary Tasks provide the execution backbone for delivery work. Next actions: * Track status cleanly: [Task Status Tracking](/transformations/task-status-tracking) * Build repeatable lists: [Task Views and Organization](/transformations/task-views-and-organization) # Task Views and Organization Build Save Views to track tasks by owner, status, and timeline. ### Overview Task views keep execution tracking readable at scale. Save Views prevent repeated filter rebuilds. {% hint style="info" %} Screenshot placeholder: Tasks area showing List/Board/Gantt options and a “Save View” control. {% endhint %} ### Key Concepts * **View type**: List, Board, or Gantt * **Filter**: rule that narrows the dataset * **Grouping**: bucket rows by a field such as Status or Owner * **Save View**: stored view configuration for repeatable reviews ### How It’s Used Use Save Views for daily triage and weekly delivery reviews. Use separate views for execution, leadership reporting, and readiness. ### Benefits * Faster standups and execution reviews * Cleaner reporting through stable filters and columns * Reduced confusion from inconsistent ad hoc views ### Setup Steps #### Common view patterns Use these patterns as starting points: * **Current teammate tasks**: `Assignee = Current Teammate` * **By status**: group by Status * **Overdue**: Due date before today and Status not Complete * **This week**: Due date within 7 days * **By workstream**: group by Process or System (when configured) #### Create a Save View {% stepper %} {% step %} ### Open Tasks 1. Open a Project. 2. Go to **Tasks**. 3. Pick a view type (List, Board, Gantt). {% endstep %} {% step %} ### Configure the view Typical controls include: * Filters (which tasks appear) * Sort (how tasks order) * Group (how tasks bucket) * Columns/fields (what you see) {% hint style="info" %} Screenshot placeholder: filter panel and grouping controls. {% endhint %} {% endstep %} {% step %} ### Save and share 1. Click **Save View** (or **Save as**). 2. Name it using a clear pattern. * For example: `Tasks — This week (Assignee = Current Teammate)` 3. Share the Save View with the team (if supported). {% endstep %} {% endstepper %} ### Best Practices * Use short, scannable view names. * Prefer 3–6 filters max. * Keep one owner field. * Avoid “multiple owners” in one task. * Hide low-signal columns. Add them only when needed. #### Troubleshooting
Task is missing from a view Check: * Filters (Assignee, Status, Process/System) * Date ranges (Due date set, time zone differences) * Archived items (when archive is enabled) Quick fix: clear filters, then re-add filters one by one.
Save View cannot be created or shared Possible causes: * Missing edit permission for views. * The Project is read-only. Ask a Project Admin to update access level.
### Summary Task views provide repeatable execution tracking. Save Views reduce filter rebuild and improve consistency. Related: * [Create and Assign Tasks](/transformations/create-and-assign-tasks) * [Creating and Customizing List Views](/getting-started/creating-and-customizing-list-views) * [Creating and Customizing Board Views](/getting-started/creating-and-customizing-board-views) * [Creating and Customizing Gantt Charts](/getting-started/creating-and-customizing-gantt-charts) * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) # Task Dependencies ### Overview Task dependencies encode sequencing constraints across execution work. They protect planning and reduce surprise blockers. ### Key Concepts * **Blocks**: upstream task must complete first * **Blocked by**: current task cannot start yet * **Related**: association without sequencing intent ### How It’s Used Use dependencies during sprint or phase planning. Use them during blocker triage. ### Benefits * Clear sequencing for execution work * Faster identification of prerequisite work * Cleaner “blocked” reporting signals ### Setup Steps {% stepper %} {% step %} ### Add a dependency 1. Open a task. 2. Locate the **Dependencies** area. 3. Select **Add dependency**. 4. Select the related task and relationship type. {% endstep %} {% step %} ### Validate sequencing intent 1. Confirm the dependency represents a true constraint. 2. Remove dependencies that are only “related context”. {% endstep %} {% step %} ### Review for cycles 1. Scan for circular dependencies. 2. Remove or re-sequence relationships when a cycle exists. {% endstep %} {% endstepper %} ### Best Practices * Keep dependencies minimal. * Use comments to document why a dependency exists. * Pair dependency review with blocked-item review. ### Summary Dependencies should represent real sequencing constraints. They should not replace links or references for general context. # Task Status Tracking ### Overview Task status communicates intent and progress. Consistent status use keeps reporting reliable. ### Key Concepts * **Status**: current state of execution work * **Status type**: reusable workflow definition * **Blocked**: explicit signal that work cannot proceed ### How It’s Used Update status during daily execution. Review status distribution during weekly governance. ### Benefits * Clear execution signals for stakeholders * Faster escalation of risk * Cleaner reporting across Projects ### Setup Steps {% stepper %} {% step %} ### Set a starting status 1. Create or open a task. 2. Set status to the correct starting state. 3. Avoid moving work to **In progress** without active execution. {% endstep %} {% step %} ### Use Blocked as a high-signal state 1. Set status to **Blocked** when progress cannot continue. 2. Add a comment with the unblock condition. 3. Add an owner for the unblock action. {% endstep %} {% step %} ### Close tasks cleanly 1. Set status to **Complete** only when acceptance criteria are met. 2. Add evidence links or notes when required. {% endstep %} {% endstepper %} ### Best Practices * Keep statuses simple and stable. * Use the same meanings across Projects when possible. * Review blocked and overdue work weekly. ### Summary Status is a shared contract for progress reporting. For status definitions and governance, see [Status Types and Meanings](/transformations/status-types-and-meanings). # Task Management ### Overview Tasks represent executable delivery work. Tasks provide ownership and progress tracking for requirements. ### Key Concepts * **Task**: unit of work assigned to a Teammate * **Task status**: workflow state for execution tracking * **Due date**: planning signal for sequencing and reviews * **Save View**: repeatable task review list ### How It’s Used Use tasks to execute requirements. Use Save Views for daily triage and weekly delivery reviews. ### Benefits * Clear ownership and accountability * Faster execution tracking through consistent statuses * Better planning through due dates and views ### Setup Steps {% stepper %} {% step %} ### Create and assign tasks * [Create and Assign Tasks](/transformations/create-and-assign-tasks) {% endstep %} {% step %} ### Standardize task views * [Task Views and Organization](/transformations/task-views-and-organization) {% endstep %} {% endstepper %} ### Best Practices * Link tasks to requirements when traceability is required. * Keep status meanings consistent across Projects. * Use Segments and Processes for reporting consistency when configured. ### Summary Task Management supports execution tracking for requirements. Views and statuses provide repeatable review workflows. Related: * [Requirements](/transformations/requirements) * [Working with Views](/getting-started/working-with-views) # Create Test Cases ### Overview Test cases validate requirements through repeatable steps. Linking tests to requirements supports coverage reporting. ### Key Concepts * **Test case**: steps and expected outcomes * **Execution result**: pass, fail, blocked, or not run (status set varies) * **Coverage**: mapping of requirements to test cases ### How It’s Used Use test cases during system testing and UAT cycles. Use linked coverage for go/no-go readiness decisions. ### Benefits * Reduced release risk through repeatable validation * Faster triage through consistent expected outcomes * Better auditability through recorded execution history ### Setup Steps {% stepper %} {% step %} ### Create a test case 1. Navigate to a Project. 2. Open **Testing**. 3. Select **New test case**. {% endstep %} {% step %} ### Define steps and expected outcome Add clear steps. Define expected outcome as an objective condition. {% endstep %} {% step %} ### Link to requirements Link the test case to one or more requirements. Use links for coverage reporting. {% endstep %} {% endstepper %} ### Best Practices * Create tests only after requirement acceptance criteria is stable. * Keep tests small and focused. * Use a consistent naming pattern, such as `{Process} — {scenario}`. ### Summary Test cases validate scope through repeatable steps. Links to requirements enable coverage tracking. Related: * [Testing](/transformations/testing) * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) * [Requirements](/transformations/requirements) # Test Organization and Views Organize test cases with saved views so execution stays clean and reviewable. ### Overview Test cases grow quickly during delivery. Views keep execution organized and reviewable. {% hint style="info" %} Screenshot placeholder: test case list with filters and a saved-view menu. {% endhint %} ### Key Concepts * **Test case**: verification step tied to scope * **Phase**: execution grouping, such as system test or acceptance test * **Status**: readiness and outcome signal * **Save View**: repeatable view configuration for execution ### How It’s Used Use test views during execution cycles. Use them during governance to review readiness and defects. ### Benefits * Faster execution through standardized views * Cleaner handoffs across testers * Better coverage visibility when tests link to requirements ### Setup Steps {% stepper %} {% step %} ### Define minimal fields Use a minimal structure: * **Status**: Draft → Ready → In progress → Passed/Failed * **Phase**: System test, acceptance test, regression * **Priority**: High/Medium/Low * **Owner**: one accountable Teammate {% endstep %} {% step %} ### Open Tests 1. Open the Project. 2. Go to **Tests**. 3. Choose List or Board view (if supported). {% endstep %} {% step %} ### Filter and group for execution Common execution views: * `UAT — Ready to run` (Phase = UAT, Status = Ready) * `UAT — Blocked` (Status = Blocked) * `Failed — Needs retest` (Status = Failed) {% hint style="info" %} Screenshot placeholder: grouping by Status with a Phase filter applied. {% endhint %} {% endstep %} {% step %} ### Save and share 1. Click **Save view**. 2. Name it with a consistent prefix. * For example: `Tests — UAT — Ready` 3. Share to the team when Project permissions allow sharing. {% endstep %} {% endstepper %} ### Best Practices * Keep status meanings consistent across execution cycles. * Keep phase names consistent across Projects when possible. * Link tests to requirements early for coverage reporting. See [Linking Tests to Requirements](/transformations/linking-tests-to-requirements). ### Troubleshooting
My test list looks empty Check: * Project selector (when multiple Projects exist) * Filters (Phase, Status, Owner) * Archived or hidden items Quick fix: clear filters, then reapply.
Status meaning differs across teams Pick a minimal workflow. Keep “Draft” and “Ready” separate. That prevents half-written tests from entering execution.
### Summary Test views keep execution structured. They also make governance review faster and more consistent. Related: * [Create Test Cases](/transformations/create-test-cases) * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) * [Filtering and Sorting Data](/getting-started/filtering-and-sorting-data) # Linking Tests to Requirements Connect test cases to requirements so coverage and traceability stay intact. ### Overview Linking tests to requirements provides end-to-end traceability. Links also surface coverage gaps before UAT. {% hint style="info" %} Screenshot placeholder: requirement detail view with a “Linked tests” section. {% endhint %} ### Key Concepts * **Coverage**: requirement to test case mapping * **Traceability**: links that connect scope to validation evidence * **Verification**: defining “done” as tested ### How It’s Used Link tests after requirement approval. Use links for coverage reporting and go/no-go readiness. ### Benefits * Clearer definition of done for scope items * Faster coverage reporting * Better audit evidence through linked results ### Setup Steps #### When to link Link tests when: * The requirement is approved and ready for verification. * A clear “done means tested” criterion is required. * Stakeholders need a coverage view. #### Link from a requirement {% stepper %} {% step %} ### Open the requirement 1. Go to **Requirements**. 2. Open the requirement to validate. {% endstep %} {% step %} ### Add linked tests 1. Find **Tests** / **Linked tests**. 2. Click **Link test** (or **Add test**). 3. Select one or more test cases. {% hint style="info" %} GIF placeholder: linking an existing test case to a requirement. {% endhint %} {% endstep %} {% endstepper %} #### Link from a test case {% stepper %} {% step %} ### Open the test case 1. Go to **Tests**. 2. Open the test case. {% endstep %} {% step %} ### Link requirements 1. Find **Requirements** / **Linked requirements**. 2. Click **Link requirement**. 3. Select the requirement(s) this test verifies. {% endstep %} {% endstepper %} ### Best Practices * Keep links **1:many** when possible. * One requirement can map to multiple tests. * Put the pass/fail criteria in the test steps. * Use a “smoke” test for broad requirements. * Add a note when coverage is intentionally out-of-scope. ### Troubleshooting
Requirement or test is not available in the link picker Common causes: * Missing access to the item Project scope. * The item is in a different Project. * Filters are applied in the picker. Try clearing filters. Then confirm access with a Project Admin.
Links do not appear in reports Check: * The change was saved after linking. * The report uses the correct Project and date filters. * The report is using requirements/test case objects (not tasks).
### Summary Linking tests to requirements provides coverage tracking. Links also support traceability for audits and readiness reviews. Related: * [Create Test Cases](/transformations/create-test-cases) * [Test Organization and Views](/transformations/test-organization-and-views) * [Requirements](/transformations/requirements) # Status Types and Meanings ### Overview Statuses communicate intent and progress consistently. Status types standardize those meanings across work items. ### Key Concepts * **Status**: state label applied to a requirement, task, or test * **Status type**: reusable workflow definition * **Governance signal**: status meaning used in reviews and reporting ### How It’s Used Use status types to standardize delivery across Projects. Use consistent meanings to protect reporting comparability. ### Benefits * Cleaner reporting signals * Faster governance reviews * Less rework caused by ambiguous status changes ### Setup Steps {% stepper %} {% step %} ### Select a minimal workflow Use a small set of states with clear meaning. For example: * Draft * Ready * In progress * Blocked * Complete {% endstep %} {% step %} ### Define meaning for each status Define “entry criteria” and “exit criteria” per status. For example, for **Blocked**: * Entry: work cannot progress due to a constraint * Exit: unblock condition is met and execution resumes {% endstep %} {% step %} ### Apply consistently Apply the same meanings across requirements, tasks, and tests when possible. Document exceptions when a separate workflow is required. {% endstep %} {% endstepper %} ### Best Practices * Keep Blocked as a high-signal status. * Avoid adding statuses for rare edge cases. * Review workflow changes quarterly. ### Summary Status types provide a shared contract for progress reporting. For setup, see [Custom Status Creation](/transformations/custom-status-creation). # Custom Status Creation ### Overview Custom statuses support delivery workflows that vary by Organization. They standardize reporting and approvals when defaults do not fit. ### Key Concepts * **Status type**: workflow definition for an item type * **Status**: state label within a workflow * **Default status**: starting state used for new items ### How It’s Used Use custom statuses when governance needs differ across Projects. Keep workflows stable to protect reporting continuity. ### Benefits * Consistent execution signals * Cleaner governance reviews * Better alignment across delivery teams ### Setup Steps {% stepper %} {% step %} ### Open status configuration 1. Navigate to **Project Settings**. 2. Open **Statuses** (or equivalent area). {% endstep %} {% step %} ### Create or edit a status type 1. Select an item type, such as Tasks or Requirements. 2. Select **Create status type** (or **Edit**). 3. Name the status type with intent. {% endstep %} {% step %} ### Add statuses and order 1. Add the required statuses. 2. Order statuses in the expected progression. 3. Set a default starting status. {% endstep %} {% step %} ### Validate reporting impact 1. Confirm Save Views and dashboards reflect the new statuses. 2. Update team guidance for meaning changes. {% endstep %} {% endstepper %} ### Best Practices * Keep workflows minimal. * Use the same status meanings across Projects when possible. * Avoid frequent changes after delivery begins. ### Summary Custom statuses should support governance and reporting. They should not be used for one-off exceptions. # Testing ### Overview Testing validates delivered scope before release. Test cases should be linked to requirements for coverage tracking. ### Key Concepts * **Test case**: validation steps with expected outcomes * **Execution**: running test cases and recording results * **Coverage**: mapping of requirements to test cases * **Save View**: repeatable testing review list ### How It’s Used Use test cases to validate requirements. Use linked tests for coverage reporting and go/no-go decisions. ### Benefits * Reduced release risk through repeatable validation * Clear audit trail for validation results * Faster scope impact analysis through linked coverage ### Setup Steps {% stepper %} {% step %} ### Create test cases * [Create Test Cases](/transformations/create-test-cases) {% endstep %} {% step %} ### Organize test views * [Test Organization and Views](/transformations/test-organization-and-views) {% endstep %} {% step %} ### Link tests to requirements * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) {% endstep %} {% endstepper %} ### Best Practices * Require acceptance criteria before creating approval-ready tests. * Keep test statuses consistent across Projects. * Use Save Views for execution tracking and go/no-go readiness. ### Summary Testing validates delivered scope through linked test cases. Coverage links support governance and reporting. Related: * [Requirements](/transformations/requirements) * [Working with Views](/getting-started/working-with-views) # Statuses ### Overview Statuses standardize workflow state across work items. Consistent meanings improve reporting and reduce execution confusion. ### Key Concepts * **Status Type**: reusable set of allowed statuses * **Status meaning**: shared definition of what each status represents * **Workflow alignment**: keeping statuses consistent across Projects ### How It’s Used Use status standards during rollout. Use them when teams report inconsistent progress tracking. ### Benefits * Cleaner reporting across Projects * Faster reviews through consistent signals * Reduced rework from ambiguous state definitions ### Setup Steps 1. Define status meanings at Account scope. 2. Apply status types consistently across Projects. 3. Review status usage quarterly and remove unused states. ### Best Practices * Keep the status set small and stable. * Document meaning and entry criteria in an internal SOP. * Avoid repurposing a status for a new meaning. ### Summary Statuses standardize workflow state and reporting. Meanings should be consistent and governed. Related: * [Status Types and Meanings](/transformations/status-types-and-meanings) * [Custom Status Creation](/transformations/custom-status-creation) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) # Working with Transformations Deliver a Project end-to-end using requirements, tasks, testing, and governance. ### Overview Transformations are the Projects where delivery work happens. Some UI labels may refer to Projects as Transformations. Transformations connect scope, execution, and validation. This connection supports traceability and governance. ### Key Concepts * **Requirement**: scope statement with acceptance criteria * **Task**: executable work that implements scope * **Test case**: validation steps linked to a Requirement * **Artifact**: supporting reference linked to delivery work * **Traceability**: relationships that connect scope to delivery and validation ### How It’s Used Use requirements to define scope. Use tasks to execute scope. Use testing to validate scope before release. ### Benefits * Clearer scope and reduced change confusion * Better accountability through ownership and status tracking * Faster audits through traceability across work items ### Setup Steps {% stepper %} {% step %} ### Capture requirements Create requirements directly. Generate requirements from artifacts when enabled. * [Requirements](/transformations/requirements) * [Requirements Management](/transformations/requirements-management) {% endstep %} {% step %} ### Plan and execute work Break requirements into tasks. Assign ownership and track progress. * [Task Management](/transformations/task-management) * [Create and Assign Tasks](/transformations/create-and-assign-tasks) {% endstep %} {% step %} ### Validate with testing Create test cases and link them to requirements. Track execution and coverage. * [Testing](/transformations/testing) * [Linking Tests to Requirements](/transformations/linking-tests-to-requirements) {% endstep %} {% endstepper %} ### Best Practices * Link tasks and tests to requirements early. * Keep statuses consistent across Projects. * Capture decisions in comments on the affected items. ### Summary Transformations connect scope, execution, and validation inside Projects. Requirements, tasks, tests, and artifacts provide end-to-end traceability. Related: * [Working with Views](/getting-started/working-with-views) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration) * [Statuses](/transformations/statuses) # How AI Powers Transform A practical overview of where AI shows up in Transform and how to use it. ### Overview AI features focus on capturing context and turning it into usable delivery output. Use this section to understand where AI appears and why it exists. ### Key Concepts * **Meeting Notetaker**: meeting capture that generates structured notes and follow-ups * **Console**: natural language query across Project content, returning answers with sources * **Knowledge Management**: practices for keeping decisions and context reusable ### How It’s Used Use Meeting Notetaker during discovery and governance meetings. Use Console during reviews when the location of an answer is unknown. Use Knowledge Management practices to reduce rework across Projects. ### Benefits * Faster conversion from meeting context to requirements and tasks * Less time spent searching for decisions and prior rationale * More consistent governance through traceable source links ### Setup Steps 1. Confirm AI features are enabled at Account scope. 2. Confirm access roles allow content visibility for the intended audience. 3. Standardize naming for Processes, Systems, and Segments to improve query precision. ### Best Practices * Keep decisions in comments with a consistent pattern, such as `Decision:` and `Approved by:`. * Prefer links to source items over copying generated text into external tools. * Use Save Views to pair AI answers with repeatable review lists. ### Summary AI workflows: * [Meeting Notetaker](/ai/meeting-notetaker) * [Console AI Search](/ai/console-ai-search) * [Knowledge Management](/ai/knowledge-management) # Meeting Notetaker Capture meetings and turn them into searchable notes and next steps. ### Overview Meeting Notetaker turns meeting discussion into structured Project context. It reduces manual note taking. It also improves traceability to delivery work. ### Key Concepts * **Capture**: meeting recording and transcription (when enabled) * **Summary**: structured notes, decisions, and action items * **Outputs**: meeting records that can be linked to requirements and tasks * **Permissions**: visibility follows Account, Organization, and Project access ### How It’s Used Use Meeting Notetaker during discovery to capture early scope. Use it during governance to record decisions and approvals. ### Benefits * Faster conversion from discussion to delivery artifacts * Reduced loss of context across teams and time * Clearer governance through searchable decisions ### Setup Steps Use the following sequence. 1. Configure the feature: [Setting Up Meeting Notetaker](/ai/setting-up-meeting-notetaker) 2. Capture meetings: [Capturing Meetings Automatically](/ai/capturing-meetings-automatically) 3. Review summaries: [Reviewing Meeting Summaries](/ai/reviewing-meeting-summaries) 4. Convert notes into requirements: [Converting Meeting Notes to Requirements](/ai/converting-meeting-notes-to-requirements) 5. Manage history: [Managing Meeting History](/ai/managing-meeting-history) ### Best Practices * Capture governance meetings consistently. * Convert action items into tasks within 24 hours. * Keep decision statements in one comment for scanability. ### Summary Meeting Notetaker creates structured context that can be linked to requirements and tasks. # Setting Up Meeting Notetaker ### Overview Meeting Notetaker requires Account-level enablement and correct permissions. Setup focuses on capture inputs, output storage, and access control. ### Key Concepts * **Enablement**: feature availability at Account scope * **Capture permissions**: microphone and recording permissions (browser and policy dependent) * **Output scope**: which Organization and Project the meeting belongs to * **Retention**: how long meeting records remain available (plan dependent) ### How It’s Used Complete setup once per Account. Revisit setup when access models or retention policies change. ### Benefits * Consistent meeting capture across delivery teams * Faster creation of requirements and tasks from discussion * Better auditability through traceable meeting sources ### Setup Steps {% stepper %} {% step %} ### Confirm feature availability 1. Confirm Meeting Notetaker is enabled for the Account. 2. Confirm the intended Organization and Project scopes exist. {% endstep %} {% step %} ### Configure permissions and capture inputs 1. Allow microphone access for the Transform domain. 2. Confirm browser settings allow audio capture when required. Related: [Browser Compatibility](/getting-started/browser-compatibility) {% endstep %} {% step %} ### Validate access to outputs 1. Confirm Teammate access is correct at Organization and Project scope. 2. Confirm meeting outputs are visible to the intended roles. Related: [Understanding Access Levels](/organizations-and-projects/understanding-access-levels) {% endstep %} {% endstepper %} ### Best Practices * Use least-privilege access for meeting content. * Capture governance meetings consistently to build continuity. * Standardize naming for Projects and meetings for easier retrieval. ### Summary Setup requires feature enablement, capture permissions, and correct access scope. # Capturing Meetings Automatically ### Overview Automatic capture reduces manual work and improves consistency. Capture produces meeting records that can be searched and linked to delivery work. ### Key Concepts * **Capture**: meeting recording and transcription (when enabled) * **Processing**: time required to generate summaries and action items * **Scope**: Organization and Project assignment for the meeting record ### How It’s Used Use automatic capture for recurring governance and delivery meetings. Use it for discovery sessions when requirements are expected outcomes. ### Benefits * Reduced note-taking overhead * Faster conversion to tasks and requirements * Higher quality context for Console search ### Setup Steps {% stepper %} {% step %} ### Confirm capture prerequisites 1. Confirm Meeting Notetaker is enabled. 2. Confirm browser permissions allow microphone access when required. {% endstep %} {% step %} ### Capture the meeting 1. Start capture using the Meeting Notetaker entry point. 2. Confirm capture status indicates recording is active. {% endstep %} {% step %} ### Wait for processing 1. Allow processing to complete. 2. Open the generated summary. Related: [Reviewing Meeting Summaries](/ai/reviewing-meeting-summaries) {% endstep %} {% endstepper %} ### Best Practices * Capture a small set of high-signal meetings first. * Use consistent meeting titles to improve search and retrieval. * Convert outputs into tasks and requirements quickly to preserve context. ### Summary Automatic capture produces meeting records that support traceability and search. # Reviewing Meeting Summaries ### Overview Meeting summaries turn captured discussion into structured notes. Review ensures accuracy before converting notes into delivery work. ### Key Concepts * **Summary**: structured narrative of topics, decisions, and action items * **Decision signal**: explicit approval or direction captured in text * **Action item**: follow-up that can become a task ### How It’s Used Review summaries after capture and processing. Use review output to create or refine requirements and tasks. ### Benefits * Fewer incorrect requirements created from misheard context * Cleaner audit trail for decisions * Better follow-through on action items ### Setup Steps {% stepper %} {% step %} ### Open the meeting record 1. Navigate to Meeting Notetaker. 2. Open the meeting record to review. {% endstep %} {% step %} ### Validate decisions and action items 1. Confirm decisions match meeting intent. 2. Confirm action items have a clear owner and outcome. 3. Add clarifying comments when needed. {% endstep %} {% step %} ### Convert high-signal items Convert scope statements into requirements. Convert action items into tasks when execution work is defined. Related: [Converting Meeting Notes to Requirements](/ai/converting-meeting-notes-to-requirements) {% endstep %} {% endstepper %} ### Best Practices * Review governance meetings first. * Capture approvals in a consistent `Decision:` pattern. * Keep requirement statements in the requirement record, not only in notes. ### Summary Summary review protects accuracy and keeps follow-through consistent. # Converting Meeting Notes to Requirements Turn captured meeting notes into draft requirements for review and refinement. ### Overview Meeting Notetaker can extract requirements-like statements from discussions. Convert them into requirements so they become trackable scope. {% hint style="info" %} Screenshot placeholder: meeting summary with “Convert to requirement” actions. {% endhint %} ### Key Concepts * **Candidate requirement**: scope statement that can become a requirement * **Draft requirement**: first-pass requirement created from notes * **Source link**: meeting record link preserved for traceability ### How It’s Used Convert meeting notes after summary review. Use conversion to preserve scope before details are lost. ### Benefits * Faster conversion from meeting outcomes to requirements * Better traceability from requirement to source discussion * Reduced manual copy/paste work ### Setup Steps Prerequisites: * Meeting Notetaker enabled at Account scope * Access to the destination Project * Permission to create requirements {% stepper %} {% step %} ### Open the meeting summary 1. Open **Meeting Notetaker**. 2. Select a meeting. 3. Review the generated summary and action items. {% endstep %} {% step %} ### Select candidate requirements Look for: * “The system must…” * acceptance criteria * rules, constraints, or approvals Avoid: * pure discussion points * open questions without a decision {% endstep %} {% step %} ### Convert and route to the right place 1. Click **Convert to requirement** (or similar). 2. Choose the destination Project (if prompted). 3. Confirm the requirement is created. {% hint style="info" %} GIF placeholder: convert a note → requirement appears in Requirements list. {% endhint %} {% endstep %} {% step %} ### Clean up the draft Do a fast polish pass: * rewrite as a single “must” statement * split multi-part notes into multiple requirements * add tags such as Process or System (when used) * add acceptance criteria bullets {% endstep %} {% endstepper %} ### Best Practices {% hint style="info" %} * Convert quickly. Edit later. Preserve context. * Keep the meeting link in the requirement description. * Add a short “Decision” line when the requirement comes from approval. {% endhint %} ### Troubleshooting
I don’t see a convert option Possible causes: * Meeting Notetaker is not enabled for the Account. * Viewer access does not include requirement creation. * The meeting summary is still processing. Try refreshing, then confirm access and feature enablement.
Converted requirements land in the wrong project If the Account has a default Project assignment: * change the Project during conversion (if prompted) * or move/copy the requirement after creation (if supported) If move/copy is not available, request support from an Account Admin.
### Summary Meeting note conversion accelerates scope capture. It also preserves traceability from requirements back to the meeting record. Related: * [Meeting Notetaker](/ai/meeting-notetaker) * [Reviewing Meeting Summaries](/ai/reviewing-meeting-summaries) * [Requirements](/transformations/requirements) # Managing Meeting History ### Overview Meeting history provides continuity across time and team changes. It supports audits, onboarding, and decision retrieval. ### Key Concepts * **Meeting record**: stored notes, summary, and linked outputs * **Retention**: how long meeting records remain available (plan dependent) * **Traceability**: links from meetings to requirements, tasks, and Artifacts ### How It’s Used Use meeting history during onboarding to recover context quickly. Use it during governance to confirm prior approvals and rationale. ### Benefits * Faster continuity for new delivery teams * Reduced repeated discussions and rework * Stronger evidence for decisions and approvals ### Setup Steps {% stepper %} {% step %} ### Find a prior meeting 1. Open Meeting Notetaker. 2. Filter or search for the meeting record. {% endstep %} {% step %} ### Reuse outputs 1. Open the meeting summary. 2. Follow links to the related requirements and tasks. 3. Convert missed items when needed. {% endstep %} {% step %} ### Archive patterns (optional) When a delivery phase ends, standardize naming or grouping to keep history searchable. {% endstep %} {% endstepper %} ### Best Practices * Keep meeting titles stable and searchable. * Convert action items into tasks within 24 hours. * Use meeting links in requirements to preserve origin context. ### Summary Meeting history is a continuity layer for decisions and follow-through. # Console ### Overview Console is a natural language interface for searching and investigation. Availability and capabilities vary by plan and permissions. ### Key Concepts * **Query**: prompt used to retrieve an answer or item set * **Sources**: links to the underlying items used to support an answer * **Scope**: Organization and Project boundaries applied to results * **Permissions**: access rules that constrain visibility ### How It’s Used Use Console to find decisions, approvals, and blockers quickly. Use it during troubleshooting to validate what changed and when. ### Benefits * Faster discovery across Projects * Better governance through linked sources * Reduced manual navigation during investigations ### Setup Steps Start with the Console workflow pages: * [Console Overview and Access](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/IHr5D4941EfyTqBdCYqy) * [Console Features and Capabilities](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/f6mM0HdSZi2Fc8RoDp6F) ### Best Practices * Start with a focused query and add constraints gradually. * Validate sources before using outputs for governance decisions. * Convert follow-up work into tasks and Save Views. ### Summary Console provides fast retrieval and investigation through natural language queries and source links. Related: * [Console Overview and Access](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/IHr5D4941EfyTqBdCYqy) * [Console Features and Capabilities](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/f6mM0HdSZi2Fc8RoDp6F) * [Console AI Search](/ai/console-ai-search) ### Overview Console provides a single place to ask questions across Transform content. It returns answers with linked sources when available. ### Key Concepts * **Scope**: Organization and Project boundaries applied to results * **Result**: item, summary, or linked source * **Access**: permissions that constrain what can be retrieved ### How It’s Used Use Console when discovery is slower than direct navigation. Use it during governance reviews to validate decisions and approvals. ### Benefits * Faster retrieval of high-signal information * Better traceability through source links * Reduced manual searching across Projects ### Setup Steps {% stepper %} {% step %} ### Confirm access Confirm access exists for the Organization and Project scope that should be searchable. {% endstep %} {% step %} ### Open Console Navigate to **Console** from the main navigation. {% endstep %} {% step %} ### Run a first query Use a focused query such as: * `blocked requirements` * `decisions about testing scope` * `overdue tasks this week` {% endstep %} {% step %} ### Validate sources Open at least one source link to confirm accuracy. {% endstep %} {% endstepper %} ### Best Practices * Keep queries short and specific. * Add one constraint at a time, such as time window or status. * Convert follow-up actions into tasks and Save Views. ### Summary Related: * [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search) * [Console Features and Capabilities](broken://spaces/bO5MkvlsUXaVsGsjqKWy/pages/f6mM0HdSZi2Fc8RoDp6F) ### Overview Console works best with focused questions. Use the patterns below. Then iterate based on results. ### Key Concepts * **Constraint**: filter term, such as time window or status * **Object type**: requirements, tasks, tests, meetings * **Sources**: links used to validate an answer ### How It’s Used Start with a short query and add constraints gradually. Validate results using source links. ### Benefits * Faster retrieval of decisions and blockers * More repeatable review questions during governance * Better traceability through explicit sources ### Setup Steps #### Good query patterns **Find specific work** * `show tasks assigned to a Teammate due this week` * `requirements related to order-to-cash` * `tests that failed in acceptance testing` **Find risk and blockers** * `what is blocked right now` * `overdue tasks by owner` * `requirements missing tests` **Find decisions** * `decisions from last 30 days` * `approvals for go-live scope` **Summarize and recap** * `summarize project progress` * `what changed since last week` * `key open questions` {% hint style="info" %} Screenshot placeholder: Console results with a “sources” list linking to items. {% endhint %} ### Best Practices * Include time windows: “this week”, “last 30 days”. * Include object types: “tasks”, “requirements”, “tests”. * Include owners: for example, “assigned to a Teammate” or “owned by a Line of Business lead”. * Ask for “sources” when traceability is required.
Examples by role Project lead: * `summarize blockers by workstream` * `overdue items by owner` Business analyst: * `requirements awaiting review` * `open questions tagged integration` Tester: * `failed tests needing retest` * `tests linked to requirement X`
### Troubleshooting
I’m getting generic results Tighten the question: * add a time window * specify a workstream (process/system) * specify an object type
I can’t find something I know exists Possible causes: * access does not include the required Organization or Project * the item title uses different wording * the item is archived or filtered out Try searching by a unique keyword from the title or description.
### Summary Query quality improves with constraints, object types, and validated sources. Store follow-up work in tasks and Save Views for repeatable governance. Related: * [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search) * [Finding Decisions and Approvals](/ai/finding-decisions-and-approvals) ### Overview Console features improve query precision and answer quality. They support repeatable governance questions and investigations. ### Key Concepts * **Query**: natural language text used to retrieve results * **Filter**: constraint on the result set, such as time window or item type * **Source**: linked item used to support an answer * **Scope**: Organization and Project boundaries applied to results ### How It’s Used Use filters and scope constraints to reduce noise. Use decision-focused patterns to improve retrieval. ### Benefits * Faster answers with fewer retries * Better auditability through linked sources * More repeatable governance workflows ### Setup Steps {% stepper %} {% step %} ### Narrow scope first Add a scope constraint when results are too broad. {% endstep %} {% step %} ### Add filters gradually Add one filter at a time, such as: * time window * status * item type (requirements, tasks, tests) {% endstep %} {% step %} ### Request sources Open at least one source link to validate answer quality. {% endstep %} {% endstepper %} ### Best Practices * Use consistent decision patterns, such as `Decision:` and `Approved by:`. * Prefer stable Process, System, and Segment naming for better retrieval. * Store repeatable review questions as a small list for governance meetings. ### Summary Related: * [Finding Decisions and Approvals](/ai/finding-decisions-and-approvals) * [Console Search Tips and Examples](/ai/console-search-tips-and-examples) # Using Console for Natural Language Search Ask questions across Transform data and jump to source items. ### Overview Console supports natural language queries across Project content. It returns answers with links to source items. {% hint style="info" %} Screenshot placeholder: Console panel showing a query, answer, and source links. {% endhint %} ### Key Concepts * **Query**: natural language prompt * **Answer**: generated response * **Sources**: item links used to support an answer * **Scope**: Organization and Project boundaries for results ### How It’s Used Use Console to answer questions without locating the source item first. Use it for cross-item questions, such as blockers, approvals, and overdue work. ### Benefits * Faster discovery of decisions and rationale * Better traceability through source links * Reduced manual navigation across Projects ### Setup Steps #### What Console can search (typical) Depending on Account configuration, Console may include: * requirements * tasks * tests * comments and activity * meeting summaries (if enabled) Results respect Account, Organization, and Project access. {% stepper %} {% step %} ### Open Console 1. Open **Console**. 2. Confirm Organization and Project scope (if prompted). {% endstep %} {% step %} ### Ask a focused question For example: * `what tasks are overdue this week` * `show blockers for order-to-cash` * `summarize progress for acceptance testing` * `find requirements that mention the ERP system` Include an object type (tasks/requirements/tests) for cleaner results. {% endstep %} {% step %} ### Open the source items 1. Review the answer. 2. Click a source link to verify details. 3. Share the source link, not a copied answer. {% endstep %} {% endstepper %} ### Best Practices {% hint style="info" %} * Add time windows: “last 7 days”, “this month”. * Add owners: for example, “assigned to a Teammate name”. * Ask for “sources” when traceability is required. {% endhint %} ### Troubleshooting
I get no results Try: * removing extra constraints * searching for one unique keyword * confirming the correct Project scope
Results don’t include an item I can see elsewhere Possible causes: * the item is in a different Project * Console indexing hasn’t caught up yet * access permissions differ by object type
### Summary Console queries should be focused and validated using sources. Use Save Views to track follow-up work surfaced by queries. Related: * [Console Search Tips and Examples](/ai/console-search-tips-and-examples) * [Finding Decisions and Approvals](/ai/finding-decisions-and-approvals) # Searching Across All Project Data ### Overview Cross-Project search supports discovery and governance reviews. Console can surface related items when the location is unknown. ### Key Concepts * **Cross-Project query**: query that spans more than one Project * **Result scope**: Organization and Project boundaries applied to results * **Source links**: traceable links to the underlying items ### How It’s Used Use cross-Project search for portfolio-style questions. Use it to find repeated decisions and common blockers across delivery work. ### Benefits * Faster discovery across Projects * Better reuse of prior decisions and patterns * Earlier visibility into cross-team delivery risk ### Setup Steps {% stepper %} {% step %} ### Confirm Organization access Confirm access exists for the intended Organization and Projects. {% endstep %} {% step %} ### Run a cross-Project query Use a query such as: * `blocked tasks across all projects` * `requirements approved this month` * `tests failing in acceptance testing` {% endstep %} {% step %} ### Validate sources and capture follow-ups Open source links and capture follow-up tasks in the correct Project. {% endstep %} {% endstepper %} ### Best Practices * Keep Process and System naming consistent across Projects. * Use Segment Types for consistent reporting dimensions. * Convert high-signal findings into tasks and Save Views. ### Summary Cross-Project search is strongest when scope is consistent and sources are verified. # Finding Decisions and Approvals Find decision notes and approval signals across tasks, requirements, and comments. ### Overview Decisions often live in comments, meeting summaries, and status changes. Console finds them without manual digging. ### Key Concepts * **Decision**: explicit direction that changes scope or execution * **Approval**: confirmation that a requirement or deliverable is accepted * **Decision pattern**: consistent formatting used for retrieval, such as `Decision:` ### How It’s Used Use this workflow during governance meetings. Use it after meetings to validate what was decided and what changed. ### Benefits * Faster decision retrieval * Clearer audit trail for approvals * Reduced rework caused by lost context ### Setup Steps {% stepper %} {% step %} ### Open Console 1. Open **Console**. 2. Confirm Project scope (if prompted). {% endstep %} {% step %} ### Use decision-focused queries For example: * `decisions from last week` * `what was approved for revenue recognition` * `show approvals for UAT scope` * `summarize key decisions for project X` {% hint style="info" %} Screenshot placeholder: Console search box with a decision query and results list. {% endhint %} {% endstep %} {% step %} ### Open the source item 1. Click the best result. 2. Jump to the original requirement/task/comment. 3. Copy the permalink for sharing, when needed. {% endstep %} {% endstepper %} ### Best Practices Use a consistent comment pattern: * `Decision:` what was decided * `Approved by:` who approved * `Date:` when it was approved * `Scope:` what it applies to For example: `Decision: Approve revenue recognition rules v2. Approved by: Line of Business lead. Date: 2026-02-17. Scope: Order-to-Cash.` ### Troubleshooting
Console results look incomplete Common causes: * access is limited to certain Organizations or Projects * decisions were captured outside Transform * decision language is inconsistent (“ok”, “yep”, “LGTM”) Fix: standardize on `Decision:` and `Approved by:` comments.
I need an audit-grade approval trail Use item history and audit trail views where available. See [Audit Trail and Compliance](/collaboration-and-automation/audit-trail-and-compliance).
### Summary Decisions are easiest to find when captured consistently and linked to the source item. Console should be used with source validation for audit-grade outcomes. Related: * [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search) * [Console Search Tips and Examples](/ai/console-search-tips-and-examples) * [Comments and Mentions](/collaboration-and-automation/comments-and-mentions) * [Comments and History](/collaboration-and-automation/comments-and-history) # Console Search Tips and Examples Query patterns you can reuse to find answers faster in Console. # Console AI Search Ask questions and find answers across Transform content. ### Overview Console supports natural language queries across Project content. It returns answers with links to source items. ### Key Concepts * **Query**: natural language prompt * **Answer**: generated response * **Source**: item links used to support the answer * **Scope**: Organization and Project boundaries applied to the query ### How It’s Used Use Console during reviews when the location of information is unknown. Use it to find decisions, blockers, and related work across item types. ### Benefits * Faster discovery of decisions and rationale * Less time spent searching across Projects * Stronger traceability through linked sources ### Setup Steps {% stepper %} {% step %} ### Run the first query Use a focused query, such as: * `blocked requirements` * `overdue tasks this week` * `decisions about testing scope` {% endstep %} {% step %} ### Validate sources Open at least one source link for verification. {% endstep %} {% step %} ### Save follow-up lists When a query identifies work to track, create a Save View for repeatable review. {% endstep %} {% endstepper %} ### Best Practices * Use real Process, System, and Segment names used in the Project. * Add one constraint at a time, such as status, owner, or date window. * Prefer specific nouns over vague adjectives. ### Summary Subpages: * [Using Console for Natural Language Search](/ai/using-console-for-natural-language-search) * [Searching Across All Project Data](/ai/searching-across-all-project-data) * [Finding Decisions and Approvals](/ai/finding-decisions-and-approvals) * [Console Search Tips and Examples](/ai/console-search-tips-and-examples) Related: * [Using Global Search](/getting-started/using-global-search) * [Getting Help](/troubleshooting/getting-help) # Knowledge Management Keep institutional knowledge organized and easy to reuse. ### Overview Knowledge management keeps delivery context reusable across Projects. It reduces rework caused by repeated discovery. ### Key Concepts * **Source of truth**: the record that should be referenced during delivery * **Traceability**: links between meeting context, requirements, tasks, and tests * **Retention**: how long information remains available (plan dependent) ### How It’s Used Use Artifacts for reference material and outputs that need a stable home. Use comments and history for decisions made in the flow of work. Use Console for retrieval across Projects when the location is unknown. ### Benefits * Faster onboarding for new delivery teams * Cleaner audits for approvals and scope changes * Less duplication across Projects ### Setup Steps {% stepper %} {% step %} ### Standardize capture locations 1. Store reference files as Artifacts. 2. Record decisions in comments using a consistent pattern. {% endstep %} {% step %} ### Link sources instead of duplicating text Link requirements, tasks, and meeting records to preserve origin context. {% endstep %} {% step %} ### Define ownership Assign ownership for the core knowledge set, such as process definitions and templates. {% endstep %} {% endstepper %} ### Best Practices * Prefer stable naming across Projects. * Archive outdated content when auditability matters. * Keep Segment Types stable to protect reporting continuity. ### Summary Start here: * [What Are Artifacts?](/artifacts/what-are-artifacts) * [Console AI Search](/ai/console-ai-search) Related: * [Comments and History](/collaboration-and-automation/comments-and-history) * [Audit Trail](/transformations/audit-trail) # Comments and Mentions Collaborate in context and pull teammates in with @mentions. ### Overview Comments keep discussion attached to the work item. @mentions create a high-signal notification to a specific Teammate. ### Key Concepts * **Comment**: message attached to an item * **@mention**: notification to a Teammate * **Permalink**: stable link to an item or comment * **Follower / watcher**: subscription to item updates (when enabled) ### How It’s Used Use comments for decisions, status updates, questions, and approvals. Use external messaging tools only for transient coordination. Summarize outcomes back into the item record for traceability. ### Benefits * Clear decision trail inside the work item * Faster reviews through in-context discussion * Reduced context loss during handoffs ### Setup Steps {% stepper %} {% step %} ### Add a comment {% hint style="info" %} Screenshot placeholder: item detail panel with the comment box highlighted. {% endhint %} 1. Open the task, requirement, or test case. 2. Locate the comment box in the detail panel. 3. Enter the message. 4. Select **Comment** (or submit with Enter). {% endstep %} {% step %} ### Mention a Teammate 1. Type `@` in the comment field. 2. Select a Teammate from the list. 3. Add the expected action and timing. {% hint style="info" %} GIF placeholder: type `@` → select a Teammate → post the comment. {% endhint %} {% endstep %} {% step %} ### Edit or delete a comment 1. Open the comment menu (⋮). 2. Select **Edit** or **Delete**. 3. Confirm the change. Edits and deletions may be limited by role and policy. {% endstep %} {% endstepper %} ### Best Practices * Keep one decision per comment when possible. * Use a consistent pattern, such as `Decision:` and `Approved by:`. * Use @mentions for action-required requests only. * Link related items instead of copying long text. ### Summary Related: * [Notification Settings](/collaboration-and-automation/notification-settings) * [Following and Watching Items](/collaboration-and-automation/following-and-watching-items) * [Comments and History](/collaboration-and-automation/comments-and-history) * [Activity Tracking](/collaboration-and-automation/activity-tracking) # Following and Watching Items Follow tasks and requirements to get notified when something changes. ### Overview Following (or watching) is a subscription to updates on an item. It’s the safest way to avoid “I didn’t see that” surprises. {% hint style="info" %} Screenshot placeholder: item header with a Follow/Watch toggle. {% endhint %} ### Key Concepts * **Follow / watch**: subscription to item updates * **Notification**: signal delivered through in-app or email * **Auto-follow**: automatic subscription caused by certain actions ### How It’s Used Follow items that require continued awareness, such as owned tasks and active requirements. Unfollow items after delivery ownership ends. ### Benefits * Less manual checking for changes * Faster response to decisions and blockers * Clearer ownership during handoffs ### Setup Steps Depending on Account configuration, notifications may include: * new comments and @mentions * status changes * reassignment * due date changes {% stepper %} {% step %} ### Follow from the item header 1. Open a task, requirement, or test case. 2. Click **Follow** / **Watch**. 3. Confirm the state changes (filled icon, “Following”, etc.). {% endstep %} {% step %} ### Follow from an action Some actions may auto-follow the Teammate: * a comment is added by the Teammate * the Teammate is @mentioned * the Teammate is assigned as owner If alert volume is high, unfollow items that are not owned. {% endstep %} {% endstepper %} ### Best Practices * Keep follow lists short to preserve signal. * Prefer @mentions over mass-following for urgent items. * Use quiet hours to control after-hours notifications. ### Summary Tune notification delivery in [Notification Settings](/collaboration-and-automation/notification-settings). Related: * [Notification Settings](/collaboration-and-automation/notification-settings) * [Comments and Mentions](/collaboration-and-automation/comments-and-mentions) * [Comments and History](/collaboration-and-automation/comments-and-history) # Team Communication Tips ### Overview Communication patterns determine whether decisions remain retrievable. These tips support scale across Organizations and Projects. ### Key Concepts * **Decision pattern**: consistent formatting used for approvals and rationale * **Thread hygiene**: keeping comments short, scoped, and linked * **Signal vs noise**: minimizing non-action messages ### How It’s Used Use these patterns during delivery and governance. Use them during onboarding to establish consistent expectations. ### Benefits * Faster reviews and approvals * Cleaner audit trail for decisions * Less repeated discussion during handoffs ### Setup Steps {% stepper %} {% step %} ### Adopt a decision format Use a consistent pattern, such as: * `Decision:` * `Approved by:` * `Date:` * `Scope:` {% endstep %} {% step %} ### Keep comments scoped 1. Ask one question per comment. 2. Reference the exact item field or acceptance criteria under discussion. 3. Link related items instead of copying long text. {% endstep %} {% step %} ### Close the loop After a decision, add a single summary comment that includes rationale. {% endstep %} {% endstepper %} ### Best Practices * Prefer links to source items for traceability. * Avoid mass @mentions. Use @mentions for action-required requests. * Summarize meeting outcomes in one comment and link the meeting record. ### Summary Communication patterns should optimize for searchability and auditability. --- [Next Page](https://help.transform.ai/llms-full.txt/1)