A practical way to collaborate?

I have taken on a coauthor for a book project and have finally run into the brick wall that is collaboration. It seems that the only practical way to collaborate is to work on the same cloud doc with some sort of gatekeeper to make sure that you both do not open the doc at the same time–and I don’t know what that gatekeeper is.

I have wasted a couple of days over the past week trying to use the built-in sync function, but, as so many have noted, it randomly fails, freezing the system and requiring a force quit. I’ve just been experimenting with the last chapter to begin freezing and have isolated the problem to two short sections. If they’re in the trash, it syncs; if not, it freezes. I just removed styles from headers in those sections (same styles in every other section that doesn’t fail), and now it syncs. So maybe if you have no styles in your doc it will sync OK?

Any advice on how to work in Scrivener with a coauthor would be appreciated.

If it were me, I’d use the Import and Merge function.

Collaborator A owns the “master” copy of the project. They use the File → Backup → Backup To function to create a copy, which they email (ZIP first) to Collaborator B.

Collaborator B makes whatever edits they like on their own schedule, then creates a backup and emails (or shares using any convenient method) to Collaborator A.

Collaborator A opens their master copy, then uses the File → Import → Scrivener Project command to import Collaborator B’s version. Scrivener will recognize that you’re importing a copy and give you several options. For full details, see Section 5.3 of the Mac Scrivener manual, starting with page 76. Then Collaborator A creates a fresh copy – reflecting A’s changes – and sends it back.

The same approach will work with multiple collaborators, provided that everyone is clear about which copy is the master and which collaborator “owns” it. In a large project with collaborators in multiple organizations, each organization might work on their own “local” master before merging back to the main source.

This approach isn’t perfect – see the discussion in the manual for a full list of limitations and caveats – but I like it because (1) all collaborators can use Scrivener as they normally would, (2) it doesn’t depend on any technologies beyond Scrivener and email, both of which I trust, and (3) done correctly, it creates a clear record of who changed what when, making it easier to revert if necessary, and also easier to resolve any debates about whether a given co-author exceeded their mandate.


There is a known bug involving Styles and the Sync with External Folder functionality. We’re working on it, but don’t have a fix yet.

It’s not up on the site yet, but we recorded a webinar on collaboration on Friday. It doesn’t cover Import and Merge (which made me sad, I love that feature), but does talk in depth about Scrivener’s revision markup and collaborating with authors who don’t use Scrivener. Once it’s ready, it will be here: Webinar Library | Literature and Latte

1 Like

Thank you. This will be the next avenue I will try. As my collaborator is mainly working on just a few chapters, I will try the method described in the first full paragraph on p. 79 of the Mac manual–File…Save As…, then delete all the chapters that my collaborator doesn’t need now.

With the Save As command, be sure to give the new project a unique name, and when you’re done editing it be sure that you’ve switched back to “your” version. Save As is a common cause of confusion among multiple copies.

1 Like

You might try collaborating over Google Docs, and then import he resulting document into Scrivener.

1 Like

First experiences with “master” and “remote” copies, using Import and Merge, have worked well. Combined with Revision Mode, this seems to be what we need. Thanks again to kewms.

My scheme is to make a backup zip file, then replace the “-bak#” in the file name with my coauthor’s initials and a number that increments with each version. That file then gets copied into a shared folder on Dropbox. There is a Project Note with the current version.

Google Docs is great for some things, but this is a really big project with lots of research files and so forth, so keeping everything in Scrivener is important.


Thanks for the update. The number of collaborations where both authors are using Scrivener seems to be small relative to the number involving Word at some point, so hearing about “real world” experiences is very helpful.

1 Like

Progress update on collaboration. It has been working well with two main issues at the moment. I’ll call these “Main” and “Remote” copies of the project.

  • Problem: Import and Merge seems to overwrite changes made to the Main copy. We’re avoiding this manually; if Remote is working on Chapter 12, I label that with red in the Main project binder to remind me to stay out of it until Remote says it’s mine to work on again. If I make changes to that section and then do Import and Merge, I lose those changes.

  • Problem: image paths. This book has hundreds of figures, so we’re using Insert…Image Linked to File…, with links to a folder in Dropbox. However, any links that I put in show up as missing files in Remote because the path names are absolute, and vice versa. As requested elsewhwere in the forum, the ability to use relative paths that don’t depend on the user-specific part of the path would solve this problem (see post for specifics).

I have a need for collaboration between several biology researchers writing a paper. As a software engineer, we collaborate all the time. Having used scrivener myself and seen its folder structure, would this workflow work.

I am really over Google docs, Office 365 for collaboration - they are not very good.


  • All use the same version of Scrivener.
  • Basic knowledge of Git (one team member may have advanced skills to fix any issues)
  1. Project Owner creates a Scrivener project on their laptop, with multiple sections - one per contributor
  2. Create a GitHub (GH) repo, and add the project to repo.
  3. Other project members clone the repo from GH onto their local machines
  4. Each person works ONLY on their section, and commits their work locally into Git and then pushed to GH in the cloud.
    a) Other team members pull latest changes from the cloud, to see what others are doing
  5. Common sections (bibliography/references) are edited by one person at a time - by verbal agreement.

The idea here is to avoid merging multiple changes to one piece of text - this can be done, but requires more git knowledge or another UI merge tool. In my case this is not practical for non-programmers.


You’re welcome to try it – make sure you have good backups! – but we do not recommend using Git with Scrivener projects.

The reason is that Git is optimized around plain text (code), while the components of a Scrivener project are RTF. Any kind of formatting change will introduce markup changes that are not really human readable.

You could reduce the “noise” in the RTF files by using markdown, rather than rich text formatting. You might also want to have a look at Scrivener’s own Import and Merge feature, discussed up thread.

When I’ve worked on projects like this as a ghost writer, my approach was to have the contributors use Word’s Tracked Changes features – which they were all familiar with – and use Scrivener to incorporate their edits into my own “master” copy.

Thanks, I think we will pass - too much messing around.

1 Like