Templates are how org admins package up a recurring Researcher setup so users can spin up the same kind of project in one click. If your team runs the same workflow against ten customers a quarter, a template is the difference between "configure ten projects from scratch" and "pick the template, hit go."
There are two types of template in Researcher: org templates, which are created by org admins and scoped to your organisation, and system templates, which are created by P-admins and available across every organisation with the relevant product enabled. This guide covers both.
This guide is for org admins. Users don't create templates — they consume them when starting a new project.
What a template captures
A template is a blueprint for a project. When a user picks a template at project creation, every one of these gets pre-filled into the new project:
Captured | What this gives the user |
Identity (name, description, icon, colour) | A recognisable card in the template picker |
Instructions / system prompt | The standing brief — the AI behaves consistently from message one |
Launch greeting and starter instructions | Optional opener text that appears on first load |
Uploads | The shared knowledge base — same documents available in every project from this template |
MCP servers, Agent Builder agents, Evo product connectors, third-party connectors | All wiring to external tools and data already done |
Quick Actions (MFEs) | Buttons in the chat for routine triggers |
Collaborators | Default people added to every project from this template |
What it doesn't capture: anything user-specific (chats, generated artifacts, member-specific preferences). Each new project starts with a blank chat.
When to make a template
Make a template when you can answer yes to at least two of these:
More than one person on your team will do this work.
You'd reuse the same instructions every time.
You'd want the same uploads or connectors available every time.
You want the AI's outputs to be comparable across runs (same shape, same fields, same tone).
Don't make a template for a one-off project. The marginal cost of a template is small but non-zero — naming, versioning, communicating it to users. Skip the overhead when the workflow isn't recurring.
Two ways to create a template
You can either build a template from scratch using the wizard, or extract one from a project you've already configured.
From scratch is the right path when you're designing a workflow deliberately — for example, when Product or Operations has agreed on a standard playbook and wants it codified.
Extracting from a project is the right path when a project has organically become the gold-standard example and you want to capture it before it diverges. The CSM who set up their Bright Spark project well? Extract a template from it before they tweak it further.
Create a template from scratch
Open the Templates area from the org admin menu in Researcher.
Click + New template. The 6-step wizard opens.
Fill in each step (all are optional except identity):
Step 1 — Identity. Name, description, icon, colour. This is what users see in the template picker. Pick a name that describes the workflow. "CSM QBR follow-up" beats "CS Team Template 1" every time.
Step 2 — AI Instructions. The system prompt — the standing brief for the AI. Also a launch greeting and optional starter instructions if you want the first chat to open with a particular message.
Step 3 — Tools & Connectors. Add MCP servers, Agent Builder agents, and Evo product connectors. This is the Unified Connectors Editor — one screen for every kind of integration. Add only the connectors users actually need; each one is a tool the AI may call, and too many tools can degrade response quality.
Step 4 — Quick Actions. Add MFE-based actions (buttons the AI can press). Discovered automatically from the MFE registry; pick the ones relevant to this workflow.
Step 5 — Collaborators. Anyone added here will be auto-added to every project created from the template. Leave blank if projects from this template are expected to be private to whoever creates them.
Step 6 — Knowledge Base. Upload the shared documents. These get vectorised and become available in every project from the template. Watch the Upload Progress panel — files aren't ready until embedding finishes. Don't publish the template until uploads finish processing.
Click Create template. It now appears in the template picker for every user in your org.
Extract a template from an existing project
Open the project you want to use as the source.
Open the project menu (three dots on the project card, or the Settings menu inside the project).
Choose Extract as template (label may vary slightly).
The template wizard opens pre-filled with the project's instructions, uploads, connectors, agents and Quick Actions.
Review each step. The wizard is the same as the from scratch flow above — you can tweak before saving.
Click Create template.
Extraction doesn't change the original project. The template is a snapshot — later changes to the project don't affect the template, and later changes to the template don't reach back into the project.
Edit an existing template
Go to Templates in the org admin menu.
Click the template you want to edit. The edit dialog opens.
Update any step (identity, instructions, tools, Quick Actions, collaborators, knowledge base).
Save.
Changes only affect future projects. Projects created from the template before your edit keep the old configuration. There's no broadcast or auto-sync.
This is deliberate — it stops a template tweak from rewriting hundreds of in-progress projects. The price: fixing a typo in a template won't update projects users have already created from it.
If a template change needs to propagate, you'll need to tell users to create new projects from the updated template (and decide what to do with their existing ones).
Delete a template
Go to Templates in the org admin menu.
Open the template you want to delete.
Choose Delete from the template menu.
Projects created from the deleted template are unaffected — they keep their configuration. They just lose the link back to the template (the template badge on the project card disappears).
What makes a good template
A few rules of thumb from the templates people actually use:
Write instructions that survive copy-paste. If you find yourself reshaping AI responses by hand — bolding things, reordering sections, stripping fluff — write that rule into the template's instructions instead of doing it every project. The walkthrough in Getting Started shows what strict instructions look like in practice.
Keep the knowledge base focused. Five well-chosen documents beats fifty mediocre ones. The AI searches semantically across uploads, and a bloated knowledge base means more noise in the search results. If half the docs are stale references "just in case", strip them out.
Only add connectors that users actually need. Every connector is a tool the AI may consider on every turn. Twelve connectors in a template means the AI is choosing from a wider menu every time it answers — and that costs accuracy. Add the two or three that match the workflow.
Name the template after the workflow, not the team. "QBR follow-up" tells a user what the template is for. "Customer Success Team v3" tells them nothing.
Don't overload one template. If your "Customer follow-up" template tries to handle QBRs, escalations, and renewals, it'll do a mediocre job of all three. Split it.
Common pitfalls
Problem | What's actually happening | Fix |
Users create a project from the template and the AI's answers don't match the instructions | Wizard saved before uploads finished embedding, so the template is missing them | Edit the template, re-add uploads, wait for embedding to complete before users start using it |
Edit to a template hasn't taken effect for a colleague | Template edits don't propagate — only new projects pick up the change | Ask the colleague to create a fresh project from the updated template |
Template selection list is empty for users | Template not enabled for the user's org, or user doesn't have Researcher access | Confirm org enablement and role assignment (Access & Setup) |
Connector configured in the template fails when a user runs a chat | Connector requires per-user credentials (e.g. OneDrive) that the user hasn't connected | User connects the third-party service in their own project after creation; the template only carries the connector configuration, not the user's credentials |
System templates
System templates are cross-organisation project blueprints created by P-admins. Unlike org templates, they are tied to a product ID — any organisation with that product enabled will see them in their template picker automatically.
They follow the same structure as org templates: instructions, uploads, connectors, actions, and collaborators. The difference is scope and ownership.
If you are an org admin You cannot create or edit system templates. You can hide any system template you do not want your users to see — go to Templates in the org admin menu, find the system template, and toggle its visibility off for your org.
If you are a P-admin Create a system template the same way you would an org template, then assign it to a product ID before publishing. Any org with that product enabled will have access to it. Because system templates are shared across organisations, treat changes carefully — there is no per-org override, and edits affect every org using the template.