Help

Create your first project

A project is a private place for related files, the people who work on them and the rules for changing them.

1. Open Projects and choose New project. Give it a name. A project is invite-only: nobody sees it until you add them.
2. Choose Add file, then Upload a file. DOCX, XLSX and PPTX are the main formats. While Dynodoc is in testing, an original can be at most 3 MB (3,000,000 bytes). Dynodoc keeps your original and builds a reviewable copy in which every paragraph, row and shape has a stable identity.
3. Open Settings to add people and choose a role for each. The roles are described below.

Capture a change from an editor

There are two ways to bring an edit into a project. Either way, nothing reaches the team version until someone reviews and merges it.

With an add-in

Install the add-in for your editor (see Editors & add-ins), choose Sign in to Dynodoc, follow its link to approve one file in the browser, choose I approved this connection and turn capture on. Edit existing text or values, then push the changes for review. Capture works only while the pane or sidebar is open, and covers existing paragraph text, cell values and shape text.

With an edited file

Edit a copy in any editor. Open the file in the project and choose Push an edited file. Word files downloaded from Dynodoc carry hidden markers that identify each paragraph exactly; other Word files, and Excel and PowerPoint files, are matched by their content. The differences become a draft that you can submit for review. Use this route for formatting and structural changes that the add-ins do not capture.

Review a pull request

A change request appears under Pull requests: a named set of changes proposed against a specific revision of one file.

• Open a request to see each changed block before and after, with formatting and structural differences.
• If the team version changed the same content after the request was based, the overlap is shown as a conflict to resolve before merging.
• Comment on a change. Reviewers choose Approve, or Request changes and say what should change.
• The project’s review rules set how many approvals are needed. The request shows how many it has.
• An approval is tied to the version of the request you were looking at. If the request changes afterwards, the approval stops counting and the request needs a new one.

Merge, or send it back

Someone with merge permission chooses Merge. The merge adds events to the file’s history that record who proposed the change, who reviewed it and who merged it. Earlier events are not rewritten.

• You can merge selected changes and leave the rest of the request open for later.
• Choose Decline, with a note, to close a request without applying it.
• If a request lacks the approvals the rules require, an owner or manager can merge without them. The override is recorded in the audit log.
• In a connected editor, choose Preview team changes and then Apply preview to bring the merged change into your file. If the file changed after the preview, nothing is overwritten.

Restore, revert and recover

History keeps every recorded change, so older content can come back without losing newer work. Open a file’s History tab and choose Recover an earlier revision. Pick one of three operations and preview it before anything is created.

Restore earlier content

Bring selected blocks back to how they were at that revision. A block that did not exist then is proposed for deletion.

Revert changes in a range

Undo the net effect of the changes between two revisions.

Cherry-pick changes in a range

Take the net effect of the changes between two revisions and apply it on top of the current version.

Recovery creates a private draft based on the current team version. Inspect it and choose Send for review; it then follows the same approval and merge rules as any other change. Overlaps with newer work are shown as conflicts. You can also download the checkpoint as JSON or as a native DOCX, XLSX or PPTX; a native download holds the supported content, so keep the original for full fidelity.

Named versions and private drafts

Named versions

A named version marks a milestone such as “Approved for release”. In a web editor, open the version history panel, enter a Version name and an optional note, and choose Save named version. Restoring a named version adds new changes; it never removes the work that came after it.

Private drafts

A draft is a private branch of one file. Under Your drafts you can compare it with main, keep editing and open a pull request when it is ready. A draft is visible only to you until you submit it. Project-wide branches published from the command line are listed read-only under Branches; creating and merging them in the browser is not available yet.

Roles and review rules

Under Settings, review rules decide whether main is protected and how many approvals a change needs, from none to five. When main is protected, changes go through pull requests. Approvals can become stale if the author edits the request afterwards.

A project’s rules are the minimum for every file in it. A file can add stricter rules, but a rule that would weaken the project’s is rejected. Owning a file does not give review authority over the project.

Verify the history

Every recorded change goes into an append-only history in which each entry carries a hash that depends on the entry before it. Open a file’s History tab and choose Verify hash chain to recompute it. The result says that the chain is intact through a revision, or names the first revision where it does not verify.

This shows that recorded events were not altered or removed after they were written. It does not show who typed a change, and it is not an independent timestamp. Add-ins record what they observe at snapshot times, not every keystroke.

The web editors

The web editors stay available for quick edits and for documents that began there. This is the same short tour the Help & tutorials button replays in the workspace. Formats and limits are on the compatibility page.

1. Bring your documents together

   Start in the workspace. Create a document or spreadsheet, or upload a Word, Excel, PowerPoint, CSV, plain-text or LaTeX file (up to 3 MB while Dynodoc is in testing). Review the conversion notes before creating the editable copy. Your original upload remains downloadable.

2. Write and work with data

   Open the editor. Use the formatting ribbon and document tabs for writing. Use the formula bar and sheet tabs for data. Right-click text, cells or a sheet tab for editing actions. LaTeX equations can be inserted from the equation button and edited by clicking them.

3. Give people the right access

   Use Share or Team workspaces. Owners and managers organize access. Editors change content; reviewers comment and suggest; viewers read. Organization and team access flows into their folders. A direct invitation can add stronger access. Removing a direct invitation does not remove an inherited role.

4. Explore without disturbing the team

   Create a personal draft. A personal draft is your own version of the document. Try a different structure or edit a paragraph. Bring in the latest shared changes, compare your work and choose which changes to share. Review competing changes before merging.

5. Keep the reason behind a revision

   Save a named version. Name milestones such as Team review, Approved proposal or Published report. Open Who changed this? to inspect recorded edits. Restoring an earlier version adds new history; it does not erase the work that came after it.

6. Share a finished copy

   Publish from the Share panel. Create a read-only public link when the content is ready to leave your team. It shows a saved copy, without comments, original uploads or history. Choose an expiry, or revoke it whenever needed. Later edits require a new public copy.

7. Return whenever you need

   Open Help & tutorials. Replay this guide from the help button. Documents in Trash can be restored. Use original-file downloads and exports to keep a copy outside Dynodoc. Review the compatibility guide when your files use advanced Office features.

Use it as an app

You can install the workspace as a web app from a supported browser. It opens at the workspace, and you can keep it on your home screen or dock. Open your profile page and look for Install app: it shows what applies to the browser you are using.

• Chrome or Edge on a computer: the install icon in the address bar, or the menu.
• Chrome on Android: Install app or Add to Home screen.
• Safari on iPhone or iPad: Share, then Add to Home Screen.
• Safari 17 or later on a Mac: File, then Add to Dock.
• Firefox on a computer cannot install it; use another browser or a pinned tab.

The app is the same workspace in its own window. When the network is missing it shows a short “You are offline” page. It does not keep your documents or edits for offline use, and saving needs a connection. The compatibility page has the full steps and what has and has not been tested.

Version-control words, in plain language

You do not need to know Git. This table maps familiar version-control words to what Dynodoc calls them. Each file has one central history; Dynodoc is not a Git repository.

Limits and when something goes wrong

• Originals are limited to 3 MB (3,000,000 bytes) while Dynodoc is in testing. Workbook imports are limited to 3,000 rows and 100 columns.
• Add-ins capture existing text and values only, up to 2,000 paragraphs, cells or shapes per file. Use Push an edited file for anything else.
• Always read the conversion notes after an import and keep your original. Complex layouts and unsupported features can differ from the source.
• If a save is interrupted in a web editor, return to the document and choose Review recovered work. To keep recovery copies, choose File, then Keep recovery copies on this browser, on a trusted device. Recovery is local to that browser and cleared when you sign out.

More detail is on the compatibility page. If something is not covered, see Support.