--- title: "Scale your workspace" slug: "/help/account/scale-workspace" sidebar_position: 5 tags: ["guides","governance","roles","admin","best practices","organization","approval","ai","api","mcp"] last_updated: "2026-10-06T12:07:54.329Z" zendesk_id: 46508987855763 zendesk_url: "https://help.walnut.io/hc/en-us/articles/46508987855763-Scaling-Your-Walnut-Workspace-Governance-Organization-Content-Best-Practices" locale: "en-us" category: "Getting Started" section: "Walnut Guide Series" product: "demos" displayed_sidebar: "demosSidebar" --- ## **Overview** A well-governed Walnut workspace makes it easy to build, manage, and scale demos consistently across your organization. Use the following best practices — grouped into **Governance**, **Organization**, and **Content** — to keep your library clean, protected, and ready for growth. The most reliable way to maintain order is to manage things **upstream** with roles, permissions, and approval. Combine strong governance with proactive workspace management to ensure your library stays organized and aligned as your team grows. **In this guide:** - [**Workspace Best Practices At-a-Glance**](#h_01KBUILDGOV_SUMMARY) - [**Governance Best Practices**](#h_01KA9G898HM4RZ1ZKMFT7MP357) - [**Organization Best Practices**](#h_01KBUILDGOV_ORGANIZATION) - [**Content Best Practices**](#h_01KBUILDGOV_CONTENT) --- ## **Workspace Best Practices At-a-Glance** ### **Governance Best Practices** - Assign [**Admin** **roles**](#h_01KBUILDGOV_ADMINS) selectively. - Use Editor/Presenter/Viewer as your [**default roles**](#h_01KBUILDGOV_DEFAULTROLES). - [**Revert** **Editors**](#h_01KBUILDGOV_BUILDPHASES) to Presenters after builds are complete. - [**Review** **collaborators**](#h_01KBUILDGOV_COLLABS) regularly and clean up access. - Use [**Groups**](#h_01KBUILDGOV_GROUPS) to manage access in bulk. - Protect critical assets with [**restricted** **permissions**](#h_01KBUILDGOV_PROTECTEDASSETS). - [**Require approval**](#h_01KBUILDGOV_APPROVAL) before templates are published, and name your approvers. - Control [**AI access and spend**](#h_01KBUILDGOV_AI) from the AI Center, including bring your own key (BYOK). - Govern [**API keys and MCP connections**](#h_01KBUILDGOV_INTEGRATIONS). - [**Tag and label**](#h_01KBUILDGOV_TAGS_LABELS) assets (e.g., DNE, LOCK, Official, LIVE, In Progress, Archived, etc.). ### **Organization Best Practices** - Maintain a centralized [**screens** **hub** **template**](#h_01KBUILDGOV_SCREENHUB). - [**Organize** **folders**](#h_01KBUILDGOV_FOLDERS) by product, feature, team, or demo type. - Use [**build** **phase** **folders**](#h_01KBUILDGOV_PHASEFOLDERS) (e.g., Active Build, Official, Archive, Spring Roadshow, etc.). - Use [**content-specific tags**](#h_01KBUILDGOV_CONTENTTAGS) to highlight product, version, or audience. - [**Archive**](#h_01KBUILDGOV_ARCHIVE) outdated assets regularly. - [**Set and lock Brand Style**](#h_01KBUILDGOV_BRANDSTYLE) under Company Settings. ### **Content Best Practices** Use [**preset** **screen** **sizes**](#h_01KA9EZ4GK9F0Z2TNZXV93KRQ6) for consistent captures. - Use [**screen** **sections** **and** **guides (guide** **chapters)**](#h_01KBUILDGOV_SECTIONS) to structure demos. - [**Name screens**](#h_01KBUILDGOV_SCREENNAMES) descriptively and consistently. - [**Enable** **cookie** **compliance**](#h_01KBUILDGOV_BRANDSTYLE) in Company Settings. - Use [**Update demos**](#h_01KBUILDGOV_UPDATEDDEMOS) to push changes at scale. --- ## **Governance Best Practices** Governance focuses on roles, permissions, and controls that prevent misalignment and protect your workspace from accidental changes. - [Assign Admin Roles Selectively >](#h_01KBUILDGOV_ADMINS) - [Use Appropriate Default Roles >](#h_01KBUILDGOV_DEFAULTROLES) - [Adjust Roles After Build Phases >](#h_01KBUILDGOV_BUILDPHASES) - [Limit Collaborator Access >](#h_01KBUILDGOV_COLLABS) - [Use Groups for Bulk Access Management >](#h_01KBUILDGOV_GROUPS) - [Protect Critical Assets with Permissions >](#h_01KBUILDGOV_PROTECTEDASSETS) - [Require Approval Before Publishing >](#h_01KBUILDGOV_APPROVAL) - [Control AI Access and Spend >](#h_01KBUILDGOV_AI) - [Govern API Keys and MCP Connections >](#h_01KBUILDGOV_INTEGRATIONS) - [Tag & Label Assets for Governance >](#h_01KBUILDGOV_TAGS_LABELS) --- ### **Assign Admin Roles Selectively** :::note[🔐 Note] Only users with an **Admin** role can assign or change another user’s role in Walnut. ::: **Admin** access allows users to control high-impact settings across your entire Walnut workspace — including branding, integrations, permissions, approval, AI settings, and overall workspace structure. Because these settings affect every team and every asset, the Admin role should be reserved for users who actively manage **branding**, **workspace organization**, **integrations**, or **content governance**. Limit **Admin** access to only those responsible for these areas. Users who simply need to **present**, **share**, or **view** demos and playlists should be assigned the **Presenter** or **Editor** role instead. Keeping Admin permissions tightly scoped helps prevent accidental changes, maintains stability, and ensures that only the right people can make organization-wide updates. **👉 Learn more about roles:** [**Manage Roles & Permissions**](/help/account/users/roles-and-permissions) --- ### **Use Appropriate Default Roles** :::note[🔐 Note] Only users with an **Admin** role can change another user’s role in Walnut. In Walnut, the default role for new team members is **Presenter**, ensuring users do not receive editing access unless intentionally granted. ::: Walnut includes two core non-admin roles designed to support different levels of collaboration: - **Editor** – For teammates who actively build, edit, or update templates and demos. - **Presenter** – For teammates who primarily need to share or present demos without making any changes. Keep **Editor** and **Presenter** as your baseline roles to prevent unnecessary editing access and maintain a stable, well-governed workspace. **👉 Learn more about roles:** [**Manage Roles & Permissions**](/help/account/users/roles-and-permissions) --- ### **Adjust Roles After Build Phases** :::note[🔐 Note] Only users with an **Admin** role can change another user’s role in Walnut. ::: If your team builds in sprints or defined project phases, adjust roles to match the level of access needed at each stage. - **During active build phases:** Assign **Editor** to collaborators who are creating or refining templates. - **After a build is complete:** Revert those collaborators back to **Presenter** so finalized content is protected from accidental edits. This workflow keeps your workspace secure while allowing teams the flexibility they need during development. **👉 Learn more about roles:** [**Manage Roles & Permissions**](/help/account/users/roles-and-permissions) --- ### **Limit Collaborator Access** :::note 🔐 Note: Only **Admins** or the **owner** of a template, demo, or playlist can change collaborator permissions. ::: Review your **Collaborators** lists on a regular basis and remove anyone who no longer needs access to specific templates or demos. This helps keep your workspace secure and reduces the risk of unintended edits. Be mindful of **inherited** **permissions**, especially in older templates. As team structures evolve or ownership changes, clean up outdated collaborator access to maintain clarity and control across your library. **👉 Learn more about collaborators:** [**Set Access Permissions For Collaborators**](/help/account/users/collaborator-access) --- ### **Use Groups for Bulk Access Management** :::note[Note: Groups] can only be created or modified by users with an **Admin** role. ::: Simplify permission management by creating Groups based on your internal teams—for example, Sales, Customer Success, Solutions Engineering, or Product Marketing. Grant or remove access at the Group level rather than updating permissions user-by-user. This saves time, reduces errors, and keeps access aligned with team responsibilities. Using Groups also helps maintain consistent governance as new teammates join, roles change, or departments restructure. **Where to Find Groups:** Navigate to **Company Settings → Groups** to create, edit, or manage team-based access controls. ![](pathname:///images/c9cd1e646cd9e36c.png) :::note[Pro Tip] Click **Manage Group** on any group to view detailed analytics and performance metrics. This helps you track engagement, monitor activity levels, and understand how each team is using Walnut. ::: --- ### **Protect Critical Assets with Permissions** Safeguard business-critical or high-impact templates by placing them in a dedicated Protected or Official folder. This creates a clear separation between approved content and work-in-progress assets. Set the folder’s sharing permissions to **Only** **collaborators** **can** **access** to ensure that only authorized users can view or edit these templates. This approach prevents accidental changes, maintains content quality, and ensures that your most important assets remain secure and controlled. ![](pathname:///images/587bafe672cc20ed.png) **👉 Learn more:** [**Set Access Permissions For Collaborators**](/help/account/users/collaborator-access) --- ### **Require Approval Before Publishing** :::note[🔐 Note] Only an **Account owner** or **Company admin** can turn on approval or grant approval rights. ::: Folders and tags signal what's ready to share, but they don't stop anyone from sharing. Approval does. With approval on, a template has to be approved before anyone can create a demo from it or update existing demos to its latest version. - **Turn it on:** go to **Company Settings → Account settings → Content approval** and turn on **Require approval before publishing**. Every existing template starts as a **Draft**, so set up your approvers first. - **Name your approvers:** in **Company Settings → Users**, turn on **Can approve content** for each member who should sign off. By default only the Account owner can approve. Approvers must be Editors or above and need edit access to the template. - **Let re-approval run itself:** any edit to an approved template moves it to **Needs re-approval**, so changed content can't go out on an old approval. - **Filter the library by review state** (Draft, In review, Approved, Needs re-approval) to see what's waiting on your approvers. Comments and @mentions work on every template whether approval is on or not. Use them to collect feedback on the element it's about, instead of in a separate doc or thread. **👉 Learn more:** [**Review and approve templates before they're published**](/help/demos/edit/content/editorial-review) --- ### **Control AI Access and Spend** :::note[🔐 Note] Changing AI settings requires the **Edit Company Settings** permission (Admin). ::: The **AI Center** (left navigation → **AI center**) is where you govern Walnut's AI features in one place: - **Decide whether AI is on.** Turn AI feature access on or off for the workspace from **AI Center → Settings**. - **Watch usage.** The **Usage** tab shows AI consumption by feature and by user, so you can spot runaway usage early. - **Manage credits.** Where your plan uses AI credits, **Credits & billing** shows the balance and purchase history. Only Account owners and Company admins can buy credits. - **Bring your own key (BYOK).** If your policy requires AI traffic to run through your own provider accounts, connect OpenAI, Anthropic, Google, or xAI keys in **AI Center → Provider keys**, then choose a failure policy and content retention. Every change is recorded in the **Change history** panel. **👉 Learn more:** [**AI Control Center**](/help/account/ai-control-center) · [**Bring your own key (BYOK)**](/help/account/ai-control-center/byok) --- ### **Govern API Keys and MCP Connections** Walnut data can leave the app through the Customer Data API, webhooks, and AI assistants connected through the Walnut MCP. Include each one in your access reviews. - **API keys are per member.** Any member can generate their own key from the **Walnut API** card on the **Integrations** page. A key reads data for your whole company, so treat keys like passwords. Generating a new key revokes the member's previous key, and **Revoke** turns a key off. - **MCP connections follow the member's permissions.** When a member connects the Walnut MCP (for example, in Claude, ChatGPT, or Codex), they choose **Full access** or **Read-only**. The assistant can only see and change what that member can. Encourage **Read-only** for anyone who just needs answers. - **Offboard departing members** rather than just changing their role. Offboarding removes their access, signs them out, and revokes their API key. - **Webhooks** send demo activity to an endpoint you register in **Company Settings → Webhooks**. Review the endpoints there periodically. **👉 Learn more:** [**Customer Data API**](/help/api/customer-data-api) · [**Connect Walnut to Claude, ChatGPT, or Codex with the Walnut MCP**](/help/integrations/more-integrations/walnut-mcp-claude) · [**What you can do with the Walnut MCP**](/help/integrations/more-integrations/walnut-mcp-capabilities) · [**Configure webhooks**](/help/api/webhooks) --- ### **Tag & Label Assets for Governance** Use tags to quickly signal an asset’s governance status and help teams understand how each template should be used. Clear tagging makes it easier to filter, audit, and maintain your library over time. ![](pathname:///images/ba5f2a03bc3b5232.png) Tags can be created, edited, or removed in **Company** **Settings** → **Account** **Settings** → **Manage** **Tags**, or directly within the Library when managing assets. _For example:_ - **Do Not Edit** - **Official** - **Live** - **In Progress** - **Archived** Combine tags with short labels at the **beginning** of asset titles: - **DNE** – Do Not Edit - **LOCK** – Protected asset - **UPDATE** – Pending refresh **Placing labels first** ensures they remain visible and are not truncated in lists, search results, or previews, so collaborators can clearly see which assets should remain unchanged. --- ## **Organization Best Practices** Organization focuses on how you structure your workspace so teams can find, maintain, and scale content efficiently. - [Build a Clear Folder Structure >](#h_01KBUILDGOV_FOLDERS) - [Use Build Phase Folders >](#h_01KBUILDGOV_PHASEFOLDERS) - [Use Tags to Indicate Build Phase or Intent >](#h_01KBUILDGOV_CONTENTTAGS) - [Archive Outdated Assets Regularly >](#h_01KBUILDGOV_ARCHIVE) - [Centralize Official Screens & Steps with a Screen Hub Template(s) >](#h_01KBUILDGOV_SCREENHUB) --- ### **Build a Clear Folder Structure** Organize your workspace using a consistent, intuitive **folder** and **subfolder** **hierarchy** so teams always know where to find and place assets. - Create folders and subfolders by **product line**, **feature area**, **team ownership**, or **demo type** (for example, External, Internal Training, Partner, Mobile App, etc.). - Group related templates, demos, and screens within their respective folders. - Use consistent naming conventions for folders to make navigation easier and reduce duplication. ![](pathname:///images/7bf5554241384b8e.png) --- ### **Use Build Phase Folders** Manage your build lifecycle by separating content based on its current phase. For example: - **Active Build** – In-progress templates and assets - **Official / Final** – Approved, ready-to-use content - **Archive** – Retired or legacy versions Move templates and demos through these folders as work progresses to keep the status of each asset clear. :::tip[Let approval track review for you] If you've turned on [approval](#h_01KBUILDGOV_APPROVAL), you don't need an **In Review** folder. Each template's review state (Draft, In review, Approved, Needs re-approval) is shown on its library card, and you can filter the library by it. ::: :::note[🏆 Pro Tip] Combine folder structure with [tags](#h_01KBUILDGOV_TAGS_LABELS) such as **In Progress**, **Official**, and **Archived** for instant visibility into an asset’s lifecycle. ::: --- ### **Use Tags to Indicate Build Phase or Intent** Content-specific tags help teammates quickly understand how an asset should be used and where it fits within your workspace. Clear tagging improves discoverability and makes it easier to locate, audit, or refresh content based on product, audience, or use case. ![](pathname:///images/ba5f2a03bc3b5232.png) Tags can be created, edited, or removed in **Company** **Settings** → **Account** **Settings** → **Manage** **Tags**, or directly within the Library when managing assets. _Examples of intent-based tags include:_ - **Product A Hub** - **New Feature Update** - **Partner Demo** - **Training** Using consistent tags ensures teams can easily filter and identify assets across different workflows, build phases, and initiatives. --- ### **Archive Outdated Assets Regularly** Periodically review your library for outdated or unused assets and move them into an Archive folder. This helps separate legacy content from active work and keeps your workspace clean and easy to navigate. You can quickly access archived items at any time using the **Filter** **By** → **Archived** option in the Library. This makes it easy to review past versions, restore assets if needed, or confirm whether something has already been retired—without cluttering your active workspace. ![](pathname:///images/eb3537a8cd4c6437.png) Regular archiving ensures collaborators can quickly find the most current demos and templates, reducing confusion—especially for new teammates who may not yet know which assets are still in use. --- ### **Centralize Official Screens & Steps with a Screen Hub Template(s)** Create one or more **screen** **hub** templates to store official, up-to-date versions of your most important product screens and guide sequences. This becomes your team’s single source of truth for all approved visuals and flows. - Store approved screens and guide steps in the hub. - Import screens from the hub into other templates to maintain structural and visual consistency across all demos. - When updates are needed, update the hub once, then re-import or update linked assets to instantly propagate changes across dependent demos. Using a screen hub ensures every team is working from the same trusted, up-to-date assets and reduces duplicate work when product UI or messaging evolves. :::note[Pro Tip] Combine your screen hub with [preset screen sizes in the Walnut Chrome Extension](#h_01KA9EZ4GK9F0Z2TNZXV93KRQ6). Capturing all screens in the same preset (Desktop, Laptop, or Mobile) keeps proportions consistent across your entire demo library. This prevents resizing issues, alignment drift, and visual mismatches when importing screens between templates—especially important when multiple teams are building in parallel. ::: --- ## **Content Best Practices** Content best practices focus on how you structure demos and screens so they are easy to maintain, analyze, and update at scale. - [Use Preset Screen Sizes >](#h_01KA9EZ4GK9F0Z2TNZXV93KRQ6) - [Use Template Sections & Guides >](#h_01KBUILDGOV_SECTIONS) - [Name Screens Descriptively >](#h_01KBUILDGOV_SCREENNAMES) - [Enable Cookie Compliance at the Workspace Level >](#h_01KBUILDGOV_BRANDSTYLE) - [Lock Brand Style at the Workspace Level >](#h_01KBUILDGOV_BRANDSTYLE) - [Use "Update demos" for Scalable Changes >](#h_01KBUILDGOV_UPDATEDDEMOS) --- ### **Use Preset Screen Sizes** Standardize every screen capture by selecting a **preset screen size** in the [Walnut Chrome Extension](/help/demos/getting-started/chrome-extension)—Desktop, Laptop, or Mobile. Using a consistent preset keeps your captures aligned and ensures your demos look professional and uniform across teams. - Ensures consistent resolution and proportions across all screens - Keeps templates looking polished, stable, and visually aligned - Reduces resizing issues when importing screens into other templates - Helps maintain consistency when multiple teams build in parallel **👉 Learn more:** - [**Create Demos – Part 1: Chrome Extension Capabilities & Best Practices**](/help/demos/getting-started/chrome-extension-tutorial) - [**Guide to Screen Display Settings (Dynamic, Proportional, Fixed Width, Fixed Size, and View On Mobile)**](/help/demos/publish/screen-display-settings) --- ### **Use Template Sections & Guides** Break demos into clear, logical parts by organizing them with **screen** **sections** and **guides (guide** **chapters)**. Structuring your demos this way makes them easier to build, maintain, and analyze. Using screen sections and guides helps you : - Quickly identify which part of a demo needs updates or revisions - Maintain a consistent narrative structure across multiple templates - Improve analytics visibility by understanding engagement at the section or chapter level - Provide a clearer experience for viewers: **Guides (guide** **chapters)** appear in the **Guides** **Toolbar** during guided demos, making navigation easier and helping viewers understand the flow and value of the demo ![](pathname:///images/fc436d00e5932fde.png) Organized demos not only create a smoother viewer experience—they also make ongoing maintenance and optimization significantly easier for your team. --- ### **Name Screens Descriptively** **Use a descriptive naming convention for your screens.** This structure simplifies updates, makes importing smoother, and improves reporting clarity. ![](pathname:///images/7835dd19c2943b77.png) _For example:_ - **Dashboard – Main** - **Settings – Billing** - **New Customer Workflow – Step 1** Renaming screens consistently across templates ensures clarity for your team, improves search results, and supports clean governance practices. **You can rename a screen from two places:** 1. **From the screen tile:** - Hover over the screen - Click the three-dot menu (•••) - Select Rename 1. **From the Screens panel:** - Open the Screens panel on the right - Click the screen you want to rename - Edit the name directly in the name field below the thumbnail ![](pathname:///images/f4df92eda726ecb4.png) --- ### **Enable Cookie Compliance at the Workspace Level** :::note[Note] This setting can only be modified by users with an **Admin** role. ::: To meet regulatory or legal requirements such as **GDPR**, **CCPA**, and other global privacy frameworks, enable cookie compliance at the workspace level. When this setting is activated, demo viewers are prompted to provide consent before any tracking cookies are used. Enabling cookie compliance ensures: - Viewers are informed about how cookies are used - Analytics and tracking remain compliant with privacy laws - Your organization maintains proper consent records for demo interactions - A consistent, privacy-aligned experience across all demos and playlists ![](pathname:///images/5679283e2acb5673.png) You can toggle cookie compliance under **Company** **Settings** → **Account** **Settings** → **Access** **Control**, ensuring all published demos respect your organization’s compliance policies. **👉 Learn more:** [**Enabling Cookie Consent**](/help/account/compliance/cookie-consent) --- ### **Lock Brand Style at the Workspace Level** :::note[Note] This setting can only be modified by users with an **Admin** role. ::: Ensure consistency across all demos by configuring **Brand Style** at the workspace level. - Go to **Company Settings → Brand Style.** - Set your organization’s approved **colors**, **fonts**, and **logos**. - Disable **“Allow users to modify these brand style settings within the editor”** to prevent template-level overrides. This keeps your visual identity cohesive across templates, demos, and playlists, even as different teams build and update content. --- ### **Use "Update demos" for Scalable Changes** Keep demos accurate and aligned across your workspace by using the **Update** **demos** bulk update feature to push template changes to all connected demos instantly. This is one of the most efficient ways to maintain accuracy and brand alignment at scale. - Use **Update demos** to propagate those changes across every demo built from that template. - Ensure your entire library stays consistent whenever product screens, flows, or messaging evolve. :::note[With approval on] If your account requires approval, **Update demos** is available only once the template is **Approved**. An edit after approval moves it to **Needs re-approval** until it's approved again. ::: **Where to Find It:** You can access **Update** **demos** from the **Demo** **Launcher**: 1. Open any **template.** 2. Click **Create & Share Demo.** 3. In the **Existing** **Demos** list, click the **Update** **demos** button. ![](pathname:///images/decf4c8633007f10.png) ---