> For the complete documentation index, see [llms.txt](https://docs.nested-knowledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nested-knowledge.com/review-workflow/workflow-tips-and-tricks.md). # Workflow Tips & Tricks Skim for good-to-know tips in your workflow. ### Set Up A Nest Before The Work Starts

Start from a Nest Template

Building a review from a blank nest works, but a [**Nest Template**](/review-workflow/workflow-tips-and-tricks/nest-templates.md) carries over a configuration that already ran successfully — module selection, tag hierarchy, screening setup. This matters most for teams running similar review types repeatedly: an HTA submission group running the same core PICO extraction on every product can start each new nest already shaped like the last one, instead of rebuilding the same hierarchy every quarter.

Build tag hierarchies you can reuse, public and organizational

A hierarchy built once rarely stays inside one nest. Saving it as a template — public, if it's a general methodology worth sharing across Nested Knowledge's user base, or organizational, if it's specific to your team's extraction standard — means the next reviewer on a similar project starts from your structure instead of reconstructing it. See [Organizational Templates.](/account-management/organization-management/organization-settings/organizational-templates.md)

Nested Knowledge interface showing tag hierarchy templates available for reuse. — Save a tag hierarchy as a template to reuse it across similar nests.

Design your tags against the export you actually need

It's tempting to build a hierarchy around how the data reads on screen and worry about the spreadsheet later. Sketching the target export first and matching tags to it from the outset avoids a structural rebuild once extraction is already underway, when studies need re-tagging rather than just re-labeling. Worth doing even for a familiar review type, since the destination spreadsheet (a HEOR value dossier, an RWE data dictionary) often has its own fixed format a hierarchy needs to match exactly. See [Match Tags to your Exports.](/review-workflow/tagging/match-tags-to-your-exports.md) {% hint style="warning" %} Confirm your target export before applying tags. Changing a tag hierarchy after extraction can require studies to be rechecked. {% endhint %}

### Search And Screen With Fewer Surprises

Name your searches as you go

A search left with its default query as its name is fine until a nest has six of them, at which point filtering by name becomes the only way to find the one from three weeks ago. Naming each search as you run it, rather than after the fact, means every later filter or comparison already reads clearly.

Nested Knowledge interface showing a search with an editable name. — Name each search to make it easier to find and compare later.

Bring in gray literature through Other Sources

Not everything worth including comes from a database search. Conference abstracts, clinical guidelines, and other PDFs without a bibliographic record can be uploaded directly through [**Other Sources**](/review-workflow/literature-search/other-sources.md), so a guideline referenced in your protocol doesn't need a manual citation workaround. This is the standard route for the gray literature most RWE and HTA-focused reviews are required to search.

Run Core Smart Tags at the screening stage

[**Core Smart Tags**](/review-workflow/tagging/ai-tools-in-tagging/core-smart-tags.md) doesn't have to wait for included studies — running it during screening gives you Study Type, Study Location, and Study Size as filterable tags on every record before a single include or exclude decision is made. A reviewer screening a broad database pull can filter down to the study types a protocol allows before reading abstracts in detail, narrowing what needs a manual look.

Turn on retraction notifications

A retracted study that makes it into an evidence synthesis is a reporting problem, not a cosmetic one. Retraction notifications, turned on in [**Nest Settings**](/your-nests/nest-settings.md), flag a study already in your nest if it's later retracted — most useful for reviews that stay open for months between search and publication.

Filter the Activity page to find what's waiting

Between screening, tagging, and adjudication, it's easy to lose track of which studies are sitting where. The [**Activity**](/account-management/organization-management/activity.md) page's quick filters show what's queued at each stage, which answers "what's actually left to do" without opening three separate modules to check.

### Catch Tagging Problems Before Extraction Is Underway

Build a Dashboard as soon as your tags exist

The moment a tag hierarchy exists — before a single study is extracted — building a quick table in [**Dashboard**](/review-workflow/synthesis/set-up-synthesis-outputs/dashboard-editor.md#build-tables-in-dashboard) shows you what the export will actually look like: which columns exist, how they're grouped, whether an index table nests the way you intended. Finding a structural problem here costs a hierarchy edit; finding it after extracting 200 studies costs 200 re-checks.

Nested Knowledge Dashboard displaying a table built from the tag hierarchy. — Use a Dashboard table to check how your tag hierarchy will appear in an export.

Use Examine for a fast read of applied tags

Rather than opening each tag's edit view to see what's already been applied, [**Examine**](/review-workflow/tagging/configure-tagging.md#examine-applied-tags-at-a-glance), in the tag hierarchy, gives a quick read of applied tags without leaving the canvas. Useful as a confirmation pass after a bulk import or an AI extraction run, before committing to a study-by-study review.

Check the Tagging QA table

The [**Tagging QA table**](/review-workflow/tagging/configure-tagging.md#hierarchy-views) lists every tag alongside how many studies are answered, unanswered, or marked not relevant for it — a hierarchy-wide progress view rather than a per-study one. Available only under Form-Based Tagging. A reviewer checking whether a hierarchy is genuinely done before sign-off can scan this table for any tag still showing a high Unanswered count, instead of spot-checking studies at random.

### Get More Out Of Study Inspector

Open Explore for a PICO-level read

When the question is what a set of studies actually says about population, intervention, or outcome — not just whether a tag was answered — [**Explore**,](/review-workflow/study-inspector/explore-from-study-inspector.md) in Study Inspector, gives that PICO-level read without exporting anything first. The right tool when you're asking "what does this evidence base look like," rather than checking one field at a time.

Customize your columns

Study Inspector's default columns rarely match what one reviewer needs on one pass. Customizing columns to show just the tags relevant to the task at hand — sample size and outcome measure, say, for a completeness check — lets you scan a filtered study list and get an answer without opening or downloading a single study. See [Customize Columns.](/review-workflow/study-inspector/customize-columns.md)

Combine filters and saved views in Advanced Study Inspector

Filters and saved views each do useful work alone, but combining them in [**Advanced Study Inspector**](/review-workflow/study-inspector/filter-studies/advanced-study-inspector.md) — an AND-based filter stack, saved as a view you can return to — is what most teams end up relying on once a review has any real size. A recurring check, like included, full text uploaded, extraction incomplete, becomes a one-select view instead of the same five filters rebuilt every week.

Advanced Study Inspector showing filters and a saved view. — Combine filters and saved views for recurring study checks.

Filter for open access full text that never made it in

Automatic PDF retrieval doesn't always succeed even when a full text is genuinely open access. Filtering for open access full text alongside full text not uploaded surfaces exactly the studies where retrieval should have worked but didn't, narrowing follow-up to that set instead of reviewing every unretrieved study one by one. See [Full Text Import.](/review-workflow/screening/full-text-import.md#why-werent-all-open-access-pdfs-retrieved-and-matched)

### Protect Your Nest Before A Risky Change

Save a version or a copy first

Restructuring a tag hierarchy, changing screening mode, or running a bulk import are all changes worth being able to undo. Saving a version of your nest, or working from a copy, before any of them means a mistake costs a rollback, not a rebuild. See [Nest Versions.](/your-nests/nest-versions.md) {% hint style="warning" %} Save a version or copy before changing screening modes, restructuring tags, or importing data in bulk. {% endhint %}

### Turn Extracted Data Into Deliverables

Ask Synthesis Chat for a first draft

Once extraction is far enough along, [**Synthesis Chat**](/review-workflow/synthesis/navigate-synthesis-outputs/synthesis-chat.md) can generate a report section, a summary table, or an answer to a specific question, grounded in the data already in your nest. It's a starting point to edit from, not a finished deliverable — but for a first-pass evidence table, or a quick answer to how many studies reported a given outcome, it saves assembling the same thing from scratch.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nested-knowledge.com/review-workflow/workflow-tips-and-tricks.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. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.