WATCH THE REAL PRODUCT
154 full-frame scenes from the real beta. Follow Avery and Jordan through their organization, project, evidence, Word form and review—one decision at a time.
Loading the video. Captions are built in; no audio is needed.
Open this transcript and use your browser’s Find to search. Select any scene title to jump to that moment.
Follow one team from signup to inspected exports. Sources supply evidence, PICOs frame the question, and people review the answers. This example is a training draft.
Start free. Use Google or your email to create your account. You will name your organization deliberately; signing in alone does not create a team.
This is a demonstration account. Your name identifies you; the organization name identifies your team. A new team starts on Free without a payment checkout.
Open the message sent to this address. Email verification proves that you control it; it does not yet create the organization.
This is the real verification result from the received link. Continue to finish your organization setup.
Your email is confirmed. Now confirm the organization name and choose Create free organization.
A new organization starts without Demo's projects. Add your own project, sources and form rather than expecting someone else's work.
The account menu shows who you are and which organization is active. Organization administration is a separate destination.
The person who creates the organization is its owner. Invited teammates join as members; an invitation does not transfer ownership.
See what your organization has used and the limits for its current plan. New organizations start on Free.
Free, Team and Growth offer increasing capacity. Team includes up to 10 members and 10 projects for a focused group.
Limits apply immediately with no checkout. Existing projects stay; actions exceeding a selected plan's capacity are blocked.
Growth includes capacity for up to 75 projects. Existing files and projects stay in place when the plan changes.
Open Invitations to build the team. Sent, pending and accepted are different states.
Invite the intended email address. These are organization permissions; access to an individual project is assigned separately.
We invite Jordan with the standard member permissions. Check the address before creating the invitation.
The owner now sees a pending invitation. Sending it is not the same as the teammate accepting it.
Jordan opens the real invitation. An existing user can sign in; a newcomer creates an account with this invited email.
This account setup belongs to the invitation. Jordan does not need to create an independent organization first.
Dossier sends a secure confirmation link. Open the received message to continue with the invited identity.
Confirm the email that requested the link. Having an invitation URL does not grant access to a different person.
The email is confirmed. Jordan can now set their name and password before deciding whether to join.
Account setup and membership are separate. Continue returns Jordan to the invitation rather than accepting it silently.
Jordan reviews the organization and permissions, then chooses Accept invitation. Decline is available too.
Jordan has joined the same organization. The home page shows only work this account can access.
The active team is Dossier Learning Team. An invited person can also create their own organization from this menu when needed.
The owner now sees Jordan as an active member. The next question is which actions and projects Jordan needs.
Create a custom role to define permissions you can assign to teammates. It does not transfer ownership or automatically expose a private project.
A coordinator can create a named role from a starting point. This is optional team administration, not a requirement for every new user.
Here, Evidence writer starts from Standard member permissions. Its name describes the assignment; it does not grant ownership.
Check the permissions before saving. A role controls actions, while access to private projects is still shared separately.
The organization now has a named role. Changes to that role affect people who remain assigned to it.
After reopening, Jordan still has Evidence writer. Next we will share the actual project they need to work on.
Start with a recognizable project name and product type. A project brings the research context, evidence and deliverable together.
The example is explicitly marked as training. In real work, describe the submission and the context the team should share.
Choose Canada and CDA-AMC for this example. Country, assessment alignment and audience should match the intended deliverable.
Check the project details together before creating it. This does not create a PICO, upload evidence or fill a form.
The sidebar keeps PICOs, Source material and Deliverables together. Each is a different part of the same submission project.
Project access has its own controls. The organization role and a Reader or Editor grant answer different questions.
This demonstration project is now private. Only the owner and people explicitly listed as Readers or Editors can open it.
Jordan is a member but cannot open this private project yet. The coordinator needs to share this project—not create another account.
The owner adds Jordan as a Reader. This lets Jordan open the private project without editing it.
Jordan can now open the project. Reader and Editor access remain different; available actions also depend on organization permissions.
Jordan will help write and review, so the owner grants Editor access. Sharing permission is still separate from permission to edit content.
A new project has no PICO until you create one. The PICO defines the question that will help focus evidence work.
Use a recognizable title. Later, this is how a writer chooses the right research context in Autofill.
Population, intervention, comparator and outcomes are separate inputs. Setting and the comparison rationale help the team interpret them.
The expanded check explains what is missing. It is not an expert approval step, and there is no extra Final button to unlock Autofill.
Specify who and where the research question concerns. These are context inputs, not claims that a source has already proved.
Name the treatment and explain how it is assessed. This is a demonstration PICO; real submissions need the team's approved question.
State the comparison and why it belongs. Clinical and economic sources may use different comparisons that need explicit review.
Describe the effects the question needs to address. Entering an outcome here does not turn it into a study finding.
Economic outcomes and time horizon add context. Check the horizon and perspective against each selected source.
Use notes for rationale, assumptions and open questions. Here the note makes clear that the example is for training.
All required inputs are present and saved. Complete means populated—not medically validated or approved for release.
Focus hides the PICO list while you work. It does not create a different PICO or change the saved question.
Jordan opens the same saved PICO. Coordinate changes to the same section rather than assuming it merges like Word coediting.
Use your own source files, or choose a suitable prepared Library source. Uploading and preparing for AI are separate actions.
Source material is evidence for the project. A Deliverables upload has a different purpose, so check the destination.
The selected paper needs a classification before upload. Do not use one label for unlike documents simply because they were selected together.
This paper is Published study - economic data. Confirm the file and classification before uploading.
The original is stored and readable. Its status explicitly says not prepared for AI; no preparation was silently purchased.
Open the actual paper to check its identity and content. The reader is useful before any AI preparation.
Fit page helps orient you; Fit width makes reading easier. Page navigation and zoom do not change the source file.
Search the PDF itself and move through its matches. This reading tool is distinct from AI evidence retrieval.
The quote shows 11 source pages and zero additional preparation pages because saved work can be reused. Read this before starting.
After confirmation, follow the preparation progress. Your original file remains available while the source is made ready.
Details show the current stage, an estimate and recorded work. This run reuses preparation; it is not a fresh parse of the paper.
You can also choose a prepared source from Palmera Library. This is an alternative to uploading your own evidence, not a required starting point.
Search for STEP 1 and check the document type, study identifiers and destination project before choosing Use in project.
The clinical report has been added alongside the economic paper. Check its project readiness before requesting AI work.
The CSR has 4,120 pages, but this quote needs no additional preparation pages. Reuse and document size are different things.
The preparation detail view explains the current stage. We can leave it and prepare the form while the source becomes available.
This new organization's Template Library starts empty. We will upload the existing CDA-AMC training template, not invent a form from scratch.
Blank starts a new form. Upload Word brings in your file. Here we use the existing training template with its native fields.
Give the template a clear name and select the actual Word file. This file already contains authored fields; no fabricated screen is substituted.
The imported form opens in the real Word editor. Close the formatting sidebar when you need more room to see the page.
The author sees field settings: its name, guidance and purpose. The selected item still points to the actual Word field.
We rename this training field Sponsor legal name. A meaningful label helps the writer navigate without creating another answer box.
Ordinary multiline guidance can be edited here. It tells the submitter what to enter; it is not the answer itself.
Edit in Word opens a separate guidance document with Word's formatting tools. The parent form is not being replaced.
Selection matters before formatting. Here we select the text in the guidance document, not the sponsor's answer field.
The Bold command changes the real guidance document. Done will save that reviewed guidance back to its field.
The saved guidance now contains Word formatting. The sidebar directs further edits into Word so formatting is not silently flattened.
Preview shows the filling experience. It is separate from your actual project deliverable and from the author's template settings.
Selecting the field exposes contextual help in the document. The submitter reads it while working on the answer.
View in Word preserves the bold guidance and paragraph structure. This submitter view is read-only, not a second answer editor.
Close the guidance view to return to the form. The field remains the working context.
The authored template is now in the team's library. The next step creates a separate project copy from it.
Template authors can identify the intended References area, including the sample content it should replace.
Here the sample reference content is selected, not the References heading or unrelated paragraphs.
Mark the selected content as a fillable field and give it the clear name References.
Field settings and guidance describe this destination. They do not change unrelated document content.
The References flag tells Dossier where generated references belong. The sample content is marked as a prompt.
Reopening confirms the template setting persisted. New deliverables copy the prepared template; existing copies remain independent.
The project has one PICO and two sources. Its deliverable is a separate document created from a template.
Use Create from template for an editable form instance. A normal file upload is a different path.
Choose the CDA-AMC training template from My templates. Check the actual template rather than assuming Blank is the intended form.
Give this deliverable its own title and keep its destination as Deliverables. The library template remains reusable.
This is the project's own Word document. Fields to fill navigates the form; it is not a separate web version of the answers.
The project copy retains the authored guidance. Read it before typing or asking Autofill for an answer.
Close the guidance callout when you need space. The selected Word field remains ready for the answer.
The sponsor name is now visible and Saved, and the filled count advances. Filled is progress—not expert approval.
Search the field list to reach a specific part of the form. You are choosing a real field in the Word document.
The guidance explains what Study 1 design needs. It is help beside the field, not text that will be submitted.
This request uses the STEP 1 clinical study report and the project's PICO. Check both before generating.
Autofill prepares a proposed answer. The existing Word answer is not replaced simply because generation starts.
The answer appears in an editable sidebar. The Word field still contains its prompt until you choose to use the suggestion.
Expand a long suggestion before deciding. Do not judge a proposed answer from only the first visible lines.
These are the supporting source passages, with document, page and section information. Compare their meaning with the field request.
Review and edit in Word opens an isolated suggestion document. It has not yet replaced the answer in the main form.
Select the suggestion in this review document. Ordinary Word formatting tools are available here.
The reviewer changes the text colour to black without rewriting the evidence. Use reviewed suggestion applies this reviewed content.
The accepted answer is visible in its field with its citation. Saved and the updated field count confirm progress—not clinical approval.
Summarize works on this field's existing reviewed material. It is not another search across every project source.
Read the wording even when automated checks pass. Here the original safety rationale is absent from the proposed wording, so we will keep the original.
Keep my text leaves the accepted answer unchanged. You do not have to accept an AI proposal to continue working.
Applying the evidence also populated the designated References field. The reference identifies the source; it is not evidence that every claim is correct.
References contains the citation and bibliography controls. A citation in the text and its bibliography entry are related, but serve different reading needs.
For your personal library, connect Zotero using its own key-creation link and read access. Each collaborator connects their own account; this screen is not a completed connection.
Anchor a comment at the relevant field. Ask the reviewer what to check and where to find the supporting source.
Jordan sees the same answer and Avery's comment. The question stays beside the document instead of becoming a disconnected message.
The posted question remains in the author's document too. Presence shows who is connected; it is not an approval signal.
The reviewer identifies what the quoted passage supports and preserves the safety rationale. This is a training review, not formal submission approval.
The author sees the teammate's reply without exchanging another document copy.
Resolve Thread marks the discussion addressed. It is not approval of the whole dossier; the following view shows that its history is retained.
Show resolved comments to revisit the conversation. Both the request and the review response remain available.
A checklist makes a concrete review step visible to the team. Keep items specific enough to verify.
Mark this source check done after reviewing it. One completed checklist item does not declare every field finished.
Assign export inspection to Jordan. A task records responsibility; access to the private project is still a separate permission.
Jordan's inbox contains the actual assigned task. Notifications connect team actions to the person who needs to act.
Export the intended saved deliverable. DOCX preserves the accepted Word package; PDF is a rendered reading copy.
The generated DOCX appears under Your files. Download the result and inspect it before any external handoff.
Choose PDF when you need a rendered version. Export does not fill missing answers or repair unfinished content.
The project retains both exported files. Each is a result to inspect, not a claim that the clinical dossier is complete.
Jordan's task is to inspect these training exports. Responsibility is visible alongside its separate approval state.
This is the downloaded file, not a screenshot substituted for an export. Check the agency instructions and the document layout.
The Study 1 design text and citation appear in the exported table. Surrounding prompts remain because this is a training draft.
The PDF retains the source reference. Check bibliographic completeness and the requested style before a real-world handoff.
Task details show its owner, status and approval state. Finishing a task and approving it are separate actions.
Jordan marks the training-file inspection done. It still needs the authorized person's approval; this does not approve all submission content.
The authorized owner approves this specific training-file inspection. Task approval is not automatic approval of the entire clinical submission.
Jordan receives the approval outcome. The person doing the work can see that the handoff was acknowledged.
Activity brings together saved document comments, project updates and the event timeline. It helps explain what happened and who acted.
Write what was checked, what remains unfinished and who owns the next step. A file existing is not the same as a submission being ready.
The handoff says this is an incomplete training draft. Real submissions still require complete answers, appropriate evidence and the agency's checks.
The teammate can read the same project-level handoff. Project updates complement—not replace—comments anchored inside Word.
Expand the deliverable's saved comments in Activity. Both resolved messages remain readable, with links back to their document context.
A later Autofill request proposes an alternative without erasing the accepted answer. Review the new offer before deciding whether anything should change.
The lightweight editor has formatting controls. You can review and format the offer here; full Word is optional, and the offer is still separate from the document.
Add after keeps the existing answer. Insert at cursor uses the captured position. Replace entire answer deletes the old answer. Cancel makes no change; choose deliberately.
Here Replace entire answer was chosen. The new answer includes a small trial-details table. The earlier exported files do not update themselves.
A fresh PDF now includes the added trial-details table and citation on the following page. After later edits, review and export again; an earlier approval does not certify new content.
Download and inspect the reviewed files, finish the required work and follow your agency's submission process outside Dossier. Automatic submission is not a product feature.
Start with the outcome: a reviewed CDA-AMC Sponsor Evidence document that your team can hand over.
READ THE SCENE
The reports and studies behind your claims.
People decide what belongs in the answer.
A reviewed Word document or PDF.
Follow one team from first sign-in to final handoff.
Understand the destination before learning the buttons.
A convincing paragraph is not enough if the team cannot explain where it came from.
READ THE SCENE
Sources, notes and drafts live in separate places.
A polished sentence may not answer the actual field.
Bring the question, evidence and reviewers together.
Think of the last answer your team struggled to trace.
Know why evidence and review matter as much as prose.
Our team is preparing a Canadian reimbursement submission for a treatment.
READ THE SCENE
Canada • CDA-AMC Sponsor Evidence.
A clinical study report and an economic paper.
Prepare, draft, check and export.
Use the example to follow the workflow, not as clinical advice.
Recognize which parts you will replace with your real project.
Your account identifies you. The organization and project decide where you are working.
READ THE SCENE
You, the signed-in person.
Your team, permissions and plan.
One submission context with its own work.
Check the selected organization before opening a project.
Know where the project and its documents belong.
Source material is what you read and use to support the answer.
READ THE SCENE
Clinical study report: methods and study findings.
Evidence relevant to economic questions.
Keep reading the actual uploaded document.
Identify which source supports the field you need to answer.
Separate source evidence from your own explanation.
PICO describes the research question—not another evidence document.
READ THE SCENE
Which people or patients?
What is being compared?
Which effects, setting and time matter?
Describe the submission question in your team's own terms.
Understand what makes a source relevant to this question.
A form tells the team what must be addressed and where.
READ THE SCENE
The specific place to answer.
A human-readable way to find it.
Instructions that explain what belongs there.
Read the field and its guidance together.
Know what a satisfactory answer needs to cover.
You fill a project copy, not the organization's reusable template.
READ THE SCENE
The reusable starting form.
A separate document starts in Deliverables.
Your answers, citations and comments.
Keep template authoring and submission work distinct.
Know which document your edits will change.
Generating, accepting and saving are different moments.
READ THE SCENE
An offer appears for review.
You choose what enters Word.
The application confirms stored document changes.
Do not treat a visible suggestion as a saved answer.
Know exactly when the document changes.
The process is easier when every stage has a clear handoff.
READ THE SCENE
Join → team → project → PICO.
Sources → prepare → form → draft → review.
Citations → team review → save → export.
Move forward only when the previous handoff makes sense.
See how each later chapter fits the bigger picture.
Are you starting an organization or responding to an invitation?
READ THE SCENE
Use Create a free organization.
Open the invitation sent to your email.
Sign in to your existing account.
Choose the path that matches why you came to Dossier.
Avoid creating an unnecessary organization just to accept an invitation.
A newcomer can begin by creating a named Free organization.
READ THE SCENE
Use the application, not the Help-site sign-in.
Create a free organization.
Identify yourself and name the organization.
Begin with signup; inspect plans when you need more capacity.
Know which organization you are creating.
Use Google's normal sign-in when that is the account you want to work with.
READ THE SCENE
Open the native Google account chooser.
Especially important for invited people.
Finish any required application setup.
Choose Continue with Google and your intended account.
Return with the same identity you selected.
The password route includes proving that you control the email address.
READ THE SCENE
Name, email, password and organization details.
Follow the account link.
Confirm the intended organization.
Finish email verification rather than stopping at account creation.
Reach the organization entry step with verified identity.
Use a name teammates will recognize when switching between organizations.
READ THE SCENE
The person creating the team.
The team you explicitly confirm.
You can now coordinate its setup.
Confirm the organization's name before creating it.
See the intended organization selected after setup.
The invitation is for the email that the owner entered.
READ THE SCENE
The intended teammate's email.
Must match the invited identity.
Use the invited email, not a different account.
Read which email the invitation expects.
Avoid accepting with a convenient but wrong Google account.
Complete account setup in the invitation journey.
READ THE SCENE
Start from the team's link.
Use the invited address.
Review the offered membership.
Stay in the invitation path rather than independent team signup.
Reach the invitation decision without creating a separate organization.
Joining a team is an explicit choice.
READ THE SCENE
Join the inviting organization.
Do not join this organization.
Do not assume setup accepted for you.
Choose after checking the organization and invited identity.
Know whether you actually became a member.
You are not trapped in the organization that invited you.
READ THE SCENE
Keep the team you already joined.
Use the account menu when you want your own.
Its projects and plan stay separate.
Create your own organization only when you actually need one.
Keep one account with distinct memberships.
Use ordinary sign-in and organization switching for future visits.
READ THE SCENE
Use your existing account.
Choose the team you mean to work with.
Continue the saved work.
Check the organization name if expected projects are missing.
Find the original work without recreating it.
One person may coordinate, write and review; the guide's hats are not automatic app grants.
READ THE SCENE
Organizes people and access.
Prepares forms or works on answers.
Checks work within granted access.
Assign responsibilities and the permissions needed to carry them out.
Do not assume the title Reviewer automatically enables comments.
Start in the organization's Members area.
READ THE SCENE
Enter the intended email address.
Choose an appropriate available set.
The recipient still chooses whether to join.
Invite using the address the teammate will actually sign in with.
The invitation is addressed to the right person.
The owner and invitee each have a part to complete.
READ THE SCENE
The invitation exists.
They sign in and review it.
Membership is established.
Check invitation status rather than assuming email delivery completed onboarding.
Distinguish pending invitations from active team members.
For ordinary teammates, a private project needs more than organization membership.
READ THE SCENE
Organization permissions govern features.
Project sharing governs its content.
A feature grant is not a private-project invitation.
Check both when a teammate cannot do their assignment.
Understand why joining may not expose every project.
Use the project's Members view after the person joins.
READ THE SCENE
An intended team member.
Reader or Editor, as appropriate.
Have them open that project.
Grant only the access their work needs.
The teammate sees the correct project and available actions.
Choose access based on the actual work, not job title alone.
READ THE SCENE
Read accessible project material.
Write where organization permissions also allow it.
Needs appropriate editing/comment rights to write feedback.
Give a commenting reviewer the required rights, not just a Reviewer label.
Know who can change the deliverable.
Share with an appropriate group when several people need the same project access.
READ THE SCENE
The relevant colleagues.
Reader or Editor access for the group.
Membership changes affect group-derived access.
Use a group for a meaningful team, not to bypass permissions.
Understand how the group gives a person project access.
A named role is not a one-time copy of permissions.
READ THE SCENE
A shared permission definition.
People still using that role.
Role edits affect those assignments.
Consider everyone assigned before changing a role.
Expect access changes beyond the current settings screen.
An invitation does not reserve an unlimited place forever.
READ THE SCENE
The organization may have reached capacity.
Review the actual plan and usage.
Free a suitable place or confirm another available plan.
Resolve the organization's capacity, then use the pending invitation.
Do not create duplicate accounts as a workaround.
The team is ready when each person can reach the work—not when settings look complete.
READ THE SCENE
Names the project and assignment.
Opens the intended project.
Confirm the actions needed are available.
Ask the teammate to open the project and locate their task.
Move on with a functioning team, not assumed access.
Use a name that helps your team identify the submission.
READ THE SCENE
Start from the project creation action.
Name and product type.
Country, audience and HTA alignment.
For our example, create a Canadian treatment project with CDA-AMC alignment.
Know why the project exists.
The submission context must match the work you are doing.
READ THE SCENE
Where the submission is intended.
The assessment framework.
The specific form you will later choose.
Check Canada and CDA-AMC for this example.
Avoid choosing a convenient but unrelated form.
Add your ingredients deliberately.
READ THE SCENE
Define the question.
Add the supporting documents.
Create the form you will fill.
Decide what evidence and form the project needs.
Do not mistake absence of sample content for lost data.
A clear title helps when several research questions share a project.
READ THE SCENE
Start a research-context record.
Name the population or question distinctly.
Build the detail progressively.
Use a title teammates can recognize in the Autofill selector.
Select the intended PICO later without guessing.
Describe who the evidence is meant to apply to.
READ THE SCENE
The patient or participant group.
Eligibility and meaningful subgroups.
Do not silently broaden the intended population.
Use the project's actual research question, not invented clinical criteria.
A teammate can recognize a relevant study population.
The treatment and comparator must be understandable together.
READ THE SCENE
Name and describe the treatment or technology.
State the alternative being compared.
Explain why that comparator belongs in the question.
Describe the comparison the submission needs.
Avoid retrieving relevant-sounding but mismatched evidence.
Clinical and economic outcomes answer different questions.
READ THE SCENE
Effects relevant to the assessment.
Costs, resource use or value questions.
When and where the question applies.
Specify the outcomes and time horizon your team needs.
Know what a useful source passage must address.
The completeness indicator checks whether expected inputs exist.
READ THE SCENE
Expected PICO sections contain content.
A qualified person has checked the question.
Your team's judgement, not the completeness badge.
Read the PICO even when it says Complete.
Avoid looking for an extra Final button before Autofill.
A project can contain more than one research question.
READ THE SCENE
Choose its named PICO.
Choose explicit No PICO when appropriate.
Clarify the question before generating.
Match the selected context to the field you are answering.
Do not assume the last PICO used is always the right one.
A good PICO is understandable to someone who did not write it.
READ THE SCENE
Saves the PICO.
Checks the question and scope.
Agrees what evidence is relevant.
Coordinate edits to the same PICO section.
Continue with a saved, understood question.
Preparation cannot repair choosing the wrong report.
READ THE SCENE
Study, product and version match your task.
Open it and inspect relevant pages.
Know which questions it may support.
Collect the real source files before starting AI work.
Recognize your source, not just its filename.
Put evidence in the project's source area.
READ THE SCENE
Choose the files you need.
Source material, not just a deliverable upload.
Describe each file accurately.
Upload the CSR and economic paper in our example.
Find them in the correct project's source list.
Classification tells people what kind of document they are working with.
READ THE SCENE
A CSR.
The economic paper in this example.
Choose the actual type, not an arbitrary label.
Check every selected file's classification before confirming.
Avoid a batch of differently typed documents labelled alike by accident.
Make a quick check of the original now.
READ THE SCENE
Navigate pages and find relevant text.
Word files can prepare a reading preview.
Retrieve the original when needed.
Open the uploaded source and verify it is the intended report.
The document identity and visible content make sense.
You can store and read evidence before deciding to prepare it.
READ THE SCENE
The original is available.
A separate user action.
The prepared source is available for AI work.
Choose Prepare for AI when the source is useful for drafting.
Understand why an uploaded source may not yet be usable by Autofill.
The decision is explicit before preparation begins.
READ THE SCENE
What the source contains.
What this operation needs.
What the organization can currently use.
Choose Start preparation or Not now after reading the quote.
Make an informed preparation decision.
Preparation may include waiting, reading, organizing and indexing.
READ THE SCENE
Work is admitted and prerequisites checked.
Text and tables become usable evidence.
The source becomes available for AI retrieval.
Use the displayed stage, progress and details to understand what is happening.
Distinguish active work from a finished source.
Leaving the source page does not mean abandoning the preparation.
READ THE SCENE
Watch the current stage.
Prepare the PICO or form.
Check readiness and the completion notice.
Return to the same source rather than reuploading it to check progress.
Find its final Ready or reported problem state.
Prepare what the project actually needs.
READ THE SCENE
May avoid another full preparation charge.
Preparation capacity.
Separate AI-use capacity.
Inspect Usage & limits if a quote cannot start.
Do not confuse storage, preparation pages and drafting usage.
The source can now support drafting, but people still inspect its evidence.
READ THE SCENE
Available for checking.
Available to choose for AI work.
Checks passages against the question.
Verify Ready before the first Autofill run in this walkthrough.
Pass a usable, understood source to the drafting stage.
The destination determines which document you must complete.
READ THE SCENE
Open the project's output area.
Choose the appropriate template.
Use your organization's CDA-AMC form for this example.
Choose the form that matches the submission.
Open a project-specific working document.
Understand which object an edit affects.
READ THE SCENE
Reusable form and guidance.
Creates the project deliverable.
Its own answers, comments and citations.
Check whether you are authoring a template or filling a submission.
Avoid changing the wrong document.
Clear authoring makes every later user's job easier.
READ THE SCENE
Define where answers belong.
Use human-readable names.
Explain the expected answer.
Mark meaningful fields and name them clearly.
The submitter can recognize each question.
Guidance should clarify the field's purpose and evidence needs.
READ THE SCENE
What is this field asking?
Which information belongs here?
Any important formatting or content constraints.
Enter ordinary guidance beneath the field name.
A newcomer can explain what answer is expected.
Do not squeeze a rich instruction into a plain text edit.
READ THE SCENE
Use the ordinary field guidance editor.
Choose Edit in Word for formatting, lists, tables or images.
Keep the guidance attached to that field.
Choose the editing surface that represents the content faithfully.
Formatting is preserved rather than silently flattened.
Authoring controls and submission help are different surfaces.
READ THE SCENE
Edits field definitions and guidance.
Checks the filling experience.
Reads instructions and writes the answer.
Preview the form after authoring important fields.
Check that the intended guidance can actually be understood.
Use Fields to fill as a map of the Word form.
READ THE SCENE
Find a meaningful field name.
Move to the actual answer location.
Read surrounding content as well.
Select the study-design field for the first worked answer.
Know which field the next action will affect.
The guidance belongs beside the active field.
READ THE SCENE
Read-only field instructions.
Expand long instructions in place.
Open the exact formatted guidance.
Read the guidance before generating or typing an answer.
Stay oriented in the submission while understanding the question.
Different fields need different kinds of answers.
READ THE SCENE
A passage you can review and edit.
A value that must fit the field type.
Structured content needs its appropriate controls.
Respect the field's intended type.
Avoid forcing a paragraph into a date or checkbox.
Bring the field, instructions and evidence together.
READ THE SCENE
Clear fields and saved guidance.
A project copy and selected field.
Ready source and intended PICO.
Check all three before generating.
The team knows where the answer will go.
Learn the review process before requesting a whole document.
READ THE SCENE
Study design in our example.
Notice whether it is empty or already filled.
Read the exact request.
Choose Autofill for this selected field.
Know what you will compare the result against.
This run answers from the selected source, not every uploaded document.
READ THE SCENE
Appropriate for the trial's design.
A different source for a different question.
Confirm the one intended for this run.
Choose the Ready CSR for our study-design example.
Do not expect evidence from unselected sources.
Context should fit the current question.
READ THE SCENE
Use the intended research question.
Choose explicitly for suitable general fields.
Source and PICO are separate selections.
Confirm both selectors before generating.
The offer will be based on the request you intended.
Dossier combines the form's question with the chosen evidence context.
READ THE SCENE
What needs answering.
Where to look for support.
Which research context matters.
Generate only after those inputs agree.
Understand why two different fields may produce different results from one source.
The source must be usable before a field suggestion can be produced.
READ THE SCENE
The evidence is available for retrieval.
Dossier searches for relevant support.
A proposed answer appears for review.
Observe the generation state instead of repeatedly starting it.
Wait for a result or an explicit reported problem.
The first result belongs to the review surface.
READ THE SCENE
Readable, editable suggestion.
Material supporting the proposal.
Still unchanged until you apply.
Read the full suggestion in the Autofill panel.
Distinguish proposed content from accepted document content.
A relevant-sounding answer still needs source checking.
READ THE SCENE
What the suggestion says.
What the selected source actually reports.
Whether that support answers this question.
Inspect the cited passage and relevant original context.
Confirm figures, population and study attribution.
Some fields need another source—or a human decision.
READ THE SCENE
Try an appropriate different document.
A declaration or current submission date may require you.
Investigate separately; do not call it absent evidence.
Determine which case you have before taking the next action.
Do not force the CSR to invent a missing fact.
Keep control without confusing the current run with the current offer.
READ THE SCENE
Ask the running operation to stop.
Dismiss an offered suggestion.
Already applied content is not automatically undone.
Use the action matching what you want to stop or decline.
Know what will remain in Word.
Scale up only after you understand the single-field journey.
READ THE SCENE
Use the appropriate document scope.
Whole-document generation targets eligible untouched fields.
Each answer still needs judgement.
Inspect offers and any fields without support.
Do not treat generation completion as a finished submission.
First decide whether the offer answers the right question.
READ THE SCENE
Does it address the field?
Do the passages justify it?
Are qualifications and context retained?
Compare the suggestion with guidance and source evidence.
Know what you would keep and change.
The normal suggestion stays beside the working document.
READ THE SCENE
Expand long content when needed.
Make appropriate wording or basic formatting changes.
Check that meaning and support still agree.
Edit the visible suggestion before applying it.
The proposed answer reflects your intended wording.
The larger review surface supports the full document-editing experience.
READ THE SCENE
A separate review document opens.
Use the native formatting you need.
Transfer the reviewed target back deliberately.
Use full Word review for richer formatting or native citation work.
Know that you are editing a draft, not yet the parent answer.
Leaving review should not be confused with undoing a prior accepted answer.
READ THE SCENE
Cancel instead of accepting it.
Confirm discarding changes if asked.
Closing does not reverse an accepted document change.
Read the discard or close message in its actual context.
Know whether the answer was ever applied.
When there is no real existing answer, the path is simpler.
READ THE SCENE
You are satisfied with the proposal.
Apply to the selected field.
Confirm the document accepted the change.
Use the apply action and wait for Saved.
See the answer in the actual field.
Decide where the new contribution belongs.
READ THE SCENE
Keep the earlier answer and add this material.
Use the valid captured placement offered.
Deliberately discard the previous answer.
Choose placement, or Cancel if uncertain.
Avoid replacing useful prior work by habit.
Replacing the whole answer is a content decision, not a default courtesy click.
READ THE SCENE
Your existing answer and sources.
The new reviewed content.
Only the chosen replacement remains in that answer.
Read the replacement choice before confirming.
You genuinely intended to remove the earlier answer.
Apply the first useful answer before asking for another contribution.
READ THE SCENE
Review and apply its useful contribution.
Change the source and generate a new offer.
Add or replace deliberately.
Choose Add after existing answer when you intend to preserve both.
Build a combined answer through explicit reviewed applications.
Visible text does not contain all the evidence relationship.
READ THE SCENE
Copies what the browser gives the clipboard.
Applies through the source-aware review path.
A real citation object, not merely a typed number.
Use the built-in apply action when retaining evidence association matters.
Do not promise provenance from a plain text paste.
The important checkpoint is the stored answer.
READ THE SCENE
Content appears in the field.
The change is being stored.
The application acknowledges persistence.
Read the final save state before leaving or exporting.
A teammate can reopen the intended answer.
It is not another search across all project sources.
READ THE SCENE
Finds support in a chosen source.
Contains material you have brought together.
Refines that field's existing content.
Select a filled prose field you actually want to refine.
Know what content will be summarized.
Not every native field is a paragraph to summarize.
READ THE SCENE
A text or rich-text answer.
A date or checkbox needs its own control.
There is no substantive text to refine.
Choose a writable, filled prose field.
Understand why Summarize may be unavailable elsewhere.
Source-aware refinement depends on usable references and accepted evidence.
READ THE SCENE
The answer currently in the field.
Which material supports which content.
Limited source identity or setting where available.
Prefer applying supported suggestions through the normal workflow.
Do not expect unreferenced text to gain invented support.
The original is your comparison point.
READ THE SCENE
Start from the accepted document state.
A proposed refinement is produced.
The reviewer compares before accepting.
Choose Summarize field and wait for its result.
Keep the original answer until you choose to replace it.
A shorter answer is not necessarily a better answer.
READ THE SCENE
Values, units and study findings.
Limitations and conditions.
Which study each claim belongs to.
Read the original and draft with those three checks.
Know whether the draft preserves what matters.
A warning asks you to investigate; it does not settle the clinical question.
READ THE SCENE
What the check calls out.
The text and source association you started with.
Your evidence-based decision.
Check a flagged number or term in context.
Do not blindly accept or blindly dismiss a warning.
You do not have to accept a rewrite.
READ THE SCENE
Retain the current answer.
Improve the proposed draft.
Accept the reviewed replacement.
Choose the result that best serves the field.
Remember that declining is not a failed workflow.
Use native editing when the draft needs more work.
READ THE SCENE
Enter the Word review surface.
Preserve the intended facts and references.
Review the updated checks before replacing.
Use the review result, not the old warnings from before your edits.
Accept only the version you have actually reviewed.
Summarize replaces the field; it does not append like an Autofill placement choice.
READ THE SCENE
Your current accepted answer.
The replacement you choose.
The field now contains that version.
Choose Replace field text deliberately and confirm Saved.
Do not expect both full original and summary in the answer.
The summary is still submission content that people own.
READ THE SCENE
Checks the saved wording.
Checks figures, references and context.
Tracks remaining concerns.
Review the accepted answer as part of the whole document.
Continue with a clearer, defensible draft.
A claim, its citation and the bibliography have different jobs.
READ THE SCENE
What the answer says.
Points to its supporting source.
Lets someone identify and find the source.
Check all three, not just a visible citation number.
A reader can follow the evidence trail.
Team work does not require inventing a shared group library.
READ THE SCENE
The reference records you maintain.
Your personal connection setup.
Browse and choose references.
Use the Zotero setup and its personal API-key instructions.
Your library is available to your signed-in account.
A source file can support Autofill without being a personal Zotero item.
READ THE SCENE
Your evidence document in the project.
Can be created when supported content is applied.
A record you add and maintain in Zotero.
Add the source to Zotero if you want to select it manually there.
Do not assume upload imported bibliographic metadata into Zotero.
Cursor position matters before opening the picker.
READ THE SCENE
Locate the statement needing support.
Choose the intended insertion or editing position.
Open the native reference workflow.
Check the caret, then choose Add Citation.
The citation belongs to the intended claim.
Similar titles can refer to different publications.
READ THE SCENE
Find candidate references.
Title, authors, date and publication.
Choose the intended source item.
Inspect the item rather than selecting the first plausible result.
Avoid citing the wrong article about a similar treatment.
The required citation style is a document preference.
READ THE SCENE
The first citation may request one.
Choose the required style.
Inspect citations and References together.
Use the style required for this deliverable.
Do not confuse changed formatting with changed evidence.
Know whether you are updating or creating the list.
READ THE SCENE
Updates citation rendering and an existing bibliography.
Creates or updates the native References list.
Check the form's designated list or resulting location.
Use the action matching the document's state.
Confirm there is one intended generated list.
A later refresh can replace generated bibliography wording.
READ THE SCENE
Identify the source of the error.
Update the appropriate bibliographic information.
Check the resulting entry.
Correct the record rather than treating the rendered list as permanent prose.
The next refresh still gives the intended reference.
The PICO has its own rich-text citation control.
READ THE SCENE
Place the editing cursor.
Search your personal Zotero library.
Rendered with the project style.
Use the PICO toolbar rather than expecting Word's ribbon inside it.
Reopen the PICO and recognize the citation.
This is a reading task, not just a button sequence.
READ THE SCENE
Has appropriate support where required.
Identifies the intended source.
Style, metadata and content are usable.
Check leftover examples, missing metadata and source mismatches.
A reviewer can trace the important claims.
Avoid unnecessary copies that split the review conversation.
READ THE SCENE
The shared working form.
Edit within their permissions.
Read or comment with the required access.
Share the existing deliverable with the intended team.
Everyone knows which document is authoritative for the work.
Do not read more into an Online label than it says.
READ THE SCENE
Connected to Dossier.
People in that document view.
A separate human decision.
Use the right presence surface for the question you are asking.
Do not assume Online means reading your current field.
Make the issue easy for the writer to find.
READ THE SCENE
Select or locate the passage.
Explain the concern clearly.
Say what needs checking or changing.
Comment on the actual claim rather than posting an unlocated complaint.
The writer knows which content the feedback concerns.
Closing the loop is more useful than collecting comments.
READ THE SCENE
Raises a specific concern.
Checks evidence, revises and replies.
Resolves the concern when appropriate.
Read the revision before resolving its discussion.
The concern is addressed, not merely hidden.
Project activity and live Word editing are different views.
READ THE SCENE
Read the document's saved discussion.
See relevant project events and updates.
Return there to reply or resolve document comments.
Use the correct surface for reading history versus editing comments.
Avoid expecting the Activity projection to be a second Word editor.
A team needs ownership of the remaining work.
READ THE SCENE
Create a meaningful task or checklist item.
Choose an eligible colleague.
Record progress separately from content approval.
Assign the review or drafting responsibility to a real person.
Someone knows they own the next action.
A notice should lead back to the work it concerns.
READ THE SCENE
Preparation, assignment or other relevant event.
Understand what changed.
Return to the source or project item.
Open the notice and check the destination.
Continue the relevant work rather than only clearing a badge.
Word collaboration and PICO saving are not identical.
READ THE SCENE
Native document coediting.
Rich sections saved as project context.
Avoid simultaneous rewrites of the same PICO section.
Divide section ownership or communicate before overlapping edits.
Do not assume every text surface merges like Word.
A displayed draft is not proof that the latest changes are stored.
READ THE SCENE
You have a confirmed stored state.
Wait or resolve the reported state.
Contact the coordinator; do not assume writing remains allowed.
Read the actual status before leaving or exporting.
Know which work is confirmed saved.
Use your team's review process, not a completion percentage.
READ THE SCENE
Checks answers and source support.
Checks meaning, numbers and references.
Confirms remaining issues and handoff readiness.
Discuss unresolved concerns explicitly.
The team knows whether it is a draft or approved for release.
Finishing one good answer does not finish the submission.
READ THE SCENE
Find unanswered or incomplete content.
Complete what AI cannot decide.
Read across answers, tables and terminology.
Review the form against the actual submission requirements.
Know what still needs human completion.
Example instructions and placeholders need human attention.
READ THE SCENE
Helps the person filling the form.
May remain as authored body content.
Contains only what your handoff should include.
Review examples and placeholders in the actual document.
Do not mistake sample reference entries for your generated bibliography.
Late edits can change the relationship between claims and citations.
READ THE SCENE
Correct source and placement.
Matches the destination's requirement.
Complete and readable metadata.
Refresh where needed, then inspect the result.
No unresolved citation issue is hidden by a green save indicator.
Know what will travel with the document.
READ THE SCENE
Resolve in Word before exporting.
Review outstanding discussion.
Do not assume export strips it all.
Inspect review state and any information inappropriate for handoff.
The file represents the version your team intends to share.
The final file must represent stored work.
READ THE SCENE
Your current intended content.
Wait for Saved.
Create the output from accepted document content.
Do not export around an unresolved save problem.
Know the latest intended changes are stored.
The file format should fit what the recipient needs.
READ THE SCENE
An editable Word handoff.
A rendered document to inspect and share.
Useful when the recipient needs both forms.
Use More document actions → Export DOCX or Export PDF.
Choose the required output format.
Requesting an export and receiving its file are separate steps.
READ THE SCENE
An export job begins.
The document output is produced.
Retrieve the completed artifact.
Wait for completion and download; you can return to exports later.
Have an actual downloaded file, not just an export request.
The final visual check happens on the file the recipient will receive.
READ THE SCENE
Tables, page breaks and readable formatting.
Intended answers and remaining comments.
Citations, entries and placement.
Open the DOCX/PDF and check important pages.
Catch problems before handing over the file.
Dossier supports the work; your organization owns the release decision.
READ THE SCENE
The downloaded version you inspected.
Your team's designated decision-maker.
The recipient's required process.
Use your team's approval and submission process.
Know who approved which version.
You can now explain how the team got from source material to the delivered document.
READ THE SCENE
The right team had the right access.
The answers were reviewed against their sources.
The saved, exported file was inspected and handed over.
Begin your real project—or revisit any chapter where the handoff is unclear.
Remember: Uploaded ≠ Ready. Suggested ≠ Applied. Filled ≠ Approved.
Self-paced · Use ← and → to navigate · Responsibilities are not permission-role names · Reviewed 2026-10-04