A few principles before you build
Build the system before you load the data. Put your structure in place before you bulk-upload anything. A stray project or two without a template is fine. But porting in dozens of past studies, surveys, and calls with no structure is how you breed chaos — and retroactively organizing it is far more painful than setting it up once, up front. Get a baseline system in place first so you’re ready to scale. Try things in production and iterate. You don’t have to get this perfect on day one. The fastest way to find out whether a structure works is to build it, use it, and adjust. Everything here is forgiving — you can rename, drag, merge, and delete as you learn. Trial a folder; if it doesn’t earn its place, delete it. Build one path end to end first. If you have several teams or segments to support, resist building all of them in parallel. Build one segment completely — folders, fields, tags, and a template — then clone and adapt it for the rest. It’s much easier to replicate a working example than to design everything at once.The order of operations
The most streamlined sequence is:1. Building folders
Folders are your largest containers — the macro division of your data. A data object (a call, a survey response) lives in a project; a project is a container of similar data; folders group related projects together. Folders can also hold subfolders. Folders do two jobs: wayfinding (helping people find data of a certain type) and signposting (telling people where new data should go when they start a project). Worth knowing up front: folders do not limit analysis. Being inside a folder doesn’t restrict what you can pull into a doc or chat with — you can pull highlights and reels from any folder regardless of where your doc lives. A folder defaults the context when you chat at the folder level, but it’s a navigation aid, not a hard wall.How to create and organize them
To create a folder, use the New button, choose Folder, name it, and create it. To build a project or subfolder inside a folder, open the folder and use the plus (+) button in the upper-right. To move things around, drag and drop — folders and projects can be rearranged at any time. The breadcrumb trail at the top helps you navigate back up levels. You can place a project two ways: create it from the home screen and assign it to a folder, or create it from inside the folder itself. If you create a project and don’t assign a folder, it lands at the top level — drag it into place later.Decisions that make folders work
Start with the largest common denominator at the top level. Your broadest organizing dimension — a major team, business unit, audience type, or research type — should be the top level. Add subfolders beneath only where they’re warranted. Nest with purpose, not by default. Deeper structures are usually driven by multiple distinct teams sharing one workspace, where each top-level folder becomes that team’s own corner. If a top-level folder has no clear way to break down further, leave it flat. And if a folder only has one or two things in it, you probably don’t need it yet. Add folders reactively. You don’t have to decide the whole structure on day one. A natural trigger to add a subfolder is when a folder gets so full it becomes hard to scan — then split it by area or work type. You can always add the folder later and move projects into it. Use a naming convention when names repeat. If the same folder name shows up under multiple parents, add a short suffix or acronym to disambiguate — and apply it consistently across the whole set, even the ones that happen to be unique. This matters for wayfinding and for AI: when you chat with a specific folder, identical names risk querying the wrong data. If you already organize data in another system, mirroring that naming convention makes cross-referencing easier.2. Building workspace fields
Fields are the metadata of your data — information that’s true for the entire object it’s applied to. The test is simple: is this true for the whole thing I’m applying it to? A participant’s persona, plan type, platform, region, or study type stays true for the whole call, so each is a field. Fields are the micro-level classification that carries the unspoken context you’ll want to filter by long term, which is why they’re worth treating as a requirement rather than a nice-to-have. Fields come in two scopes. Workspace (global) fields are shared across projects and give your team a common language for filtering — they’re pre-mapped so their options are ready to select the moment someone adds data. Project fields exist for individual work within a single project. This section is about building the workspace fields.How to create them
Workspace fields live in Settings → Structure → Fields. The flow is:Create a new field group
Use New field group to organize related fields, and name it. A common pattern is one global group plus a few segment-specific groups, which you can stack together like building blocks.
Choose the field type
Options include date, single select, multi-select, number, and text. Single select is by far the most common, so reach for that unless you have a reason not to.
Link fields to your template
A workspace field can be linked to any live project, but the most important place to link it is your template. Anyone who creates a project from that template automatically inherits the linked fields, fully mapped and ready to use. You can also attach workspace fields to existing projects retroactively, so a project or two built before the template is no problem.Lock fields down
Once your fields are built, protect them. Use Share (upper-right) and change everyone from Full access to Can use. Can use lets people select existing options but stops them creating new fields or options, or deleting anything — which matters because deleting a workspace field removes that data everywhere. Add at least one other person as a backup editor so you’re covered if you’re out.3. Building tags
Where fields describe the whole object, tags classify moments in time within it — a pain point, a competitor mention, a feature request, a moment of delight. Tags are an optional tool, not a requirement: they exist to make your work easier, not to force anyone to tag everything. Like fields, tags have two scopes. Workspace (global) tags are a shared baseline set so people don’t recreate the same tags every project — there’s no need for twenty versions of a “pain point” tag. Project tags are created freely by individuals for their specific work, and you don’t have to manage those.How to create them
Workspace tags live in Settings → Structure → Tags. Create a New tag board, then within it create groups (think of these as columns — for example, sentiment, feedback type, or topic) and create individual tags inside each group. You can rename tags inline, and if duplicates ever creep in, you can merge them. Two things make a tag system work well: Use a deliberate color system. Color builds a visual sense of where a tag belongs — otherwise the board turns into visual noise. A common approach is to color sentiment intuitively (green positive, red negative, neutral gray or yellow) and to color each other group a single shared color, including the group header, so the color itself signals the group. Write a description on every tag. Descriptions tell people when and why to use a tag, and they also feed Dovetail’s suggested highlights, which reads the tag title, its description, and what’s already been tagged to propose new highlights. Keep descriptions short and direct — instructions, essentially.Keep tags meaningful
The main pitfall is a single broad tag applied everywhere — a generic “pain point” stuck on hundreds of moments quickly balloons into noise. A few ways to avoid that:- Treat global tags as a quick-start baseline, not as the mechanism for cross-project analysis.
- Make tags more granular if you want them to stay meaningful.
- Capture truly cross-cutting themes as doc-level fields rather than broad data tags, so a report-level theme isn’t conflated with individual highlights.
- Combine tags with field filters to slice within a project — for example, a “pain point” reel narrowed to a specific plan type.
4. Assembling a project template
The template is what ties everything together. It pre-loads a new project with everything already configured so contributors don’t have to think about setup — they just rename the project, optionally drop in a brief, and upload data. You pay the setup cost once, and everyone after you spends their time on analysis instead of configuration. For a small team with a consistent workflow, one well-built template is often all you need.What a template can pre-load
- Your workspace fields, pre-mapped with options ready to select.
- Your tags, with descriptions, so suggested highlights can start matching as soon as data lands.
- Written instructions for contributors — naming conventions, where to paste the project brief, links to a training recording, and so on.
- Default views and filter settings.
- The highlight automation level.
- An overview, which feeds the AI context about the project.
How to build it
Templates live in Settings → Structure → Templates. Create a new template and name it, then:Write the overview and instructions
The overview page serves two audiences: humans deciding whether the project is relevant, and the AI, which uses it as context. Put setup instructions right here — rename the title to your convention, paste your brief, and add any links. Whatever you type appears automatically when someone creates a project from the template.
Turn on the display elements
Use the plus (+) in the upper-right to enable Highlights and Tags so they show, and set Always show filters on from the three-dot menu.
Set the automation defaults
Leave source and summary language at their default, pick a default summary framework from the available options (for example, a customer-call or jobs-to-be-done framework), and choose a highlight mode:
- Suggest (the default) — the AI proposes highlights from your tags and descriptions, and a human accepts or rejects them.
- On — the AI applies highlights automatically for you to review later.
- Off — the feature is disabled.
Link your fields and tags to the template
This is the step that makes a template more than a layout. Linking is easiest from settings, not from inside the template:- For fields: Settings → Fields → [your field group] → Link Projects → My Templates → [your template], and toggle it on. Repeat for each field group.
- For tags: Settings → Tags → [your tag board] → Link Project → [your template].
How templates behave once in use
A couple of behaviors are worth understanding:- Creating a project from a template makes a copy. Later edits to the template’s content, layout, or instructions do not flow back to projects already created — only new projects get them.
- The exception is linked fields and tag boards, which stay live-linked. Add a new tag to a linked board or a new field to a linked group, and it will appear in existing projects.
- To build templates for other segments, clone an existing template rather than starting over, then change which field groups and tag boards link to it.
5. The result: how a contributor uses it
Once the system is built, the day-to-day flow is short. A contributor picks a folder, adds a project, and chooses the template. The project arrives with fields, tags, views, automation, and instructions already in place. The only steps left are to rename the project to your convention, optionally paste in the brief, and upload the data. All the configuration is already done. After that, test it yourself: create one real project from the template and confirm the fields and tags appear as expected. Then replicate the pattern for your other segments by cloning.A note on getting data in
Two related decisions often come up while preparing a workspace. Contacts. If you manage contacts in a CRM, you can sync them so the contact fields (industry, region, revenue, and the like) populate and update automatically — you only maintain them in the CRM. You don’t need to bring in every contact; you can select a subset, typically the people you’re actively engaging. If the sync isn’t ready, you can upload contacts as a CSV now and connect the CRM later. You can also build segments — saved groups of contacts (for example, executives, or customers on a particular plan) — and reference them in chat and agents to focus analysis on a specific group. Channels vs. projects. Channels are built for continuous, high-volume feedback — the day-over-day, week-over-week streams like NPS, support tickets, and app reviews, where the value is spotting themes over time. A channel needs a high volume of data to be worthwhile. Lower-volume, periodic feedback — recurring check-ins, interviews, the occasional survey — belongs in projects, where you can still analyze it fully, ask Dovetail to surface changes over time, and run agents against it. Protecting sensitive data. Dovetail is open by default, on the principle that it’s easier to lock things down than to open them back up and remember where everything is. When you need to protect data, you have several levers: lock down the contacts database so people can see a name in a transcript but not the underlying profile and fields; lock down whole projects for sensitive areas like HR or medical data; and redact at the moment level — text, audio, or video, including blurring video by default — with workspace-level redaction rules available for information you always want hidden.Where to next
1: Plan your workspace and taxonomy
Review the thinking behind folder structure, fields, and tags before you build.
Projects
Learn how to create and manage projects in Dovetail.