Co-authoring using Office for the web

Office for the web supports multiple users editing a document at the same time. Co-authoring in Office for the web includes real-time content updates between all users editing the document, as well as presence information and real-time cursor tracking for each user.

There are no unique WOPI host requirements beyond those described in this documentation in order to support co-authoring. But the guidelines around file IDs and locks, as described in the Key concepts section, are important for enabling co-authoring.

Benefits from co-authoring support

Editing documents requires that Office for the web take a lock on the file to ensure that only Office for the web is writing to the file. In cases where co-authoring isn't supported, this causes two problems.

First, users are unable to make changes to the file while someone else is editing it. You avoid this problem when you support co-authoring. With co-authoring in Office for the web, users are never locked out of editing a document.

Second, while Office for the web makes every attempt to unlock files after users have finished editing documents, there are circumstances where this might not happen. If Unlock isn't called successfully, the file stays locked until the lock times out. This means that a user can be locked out of editing a file even if they were the one who originally locked it. When co-authoring is supported, the fact that the file is locked isn't a problem. Office for the web allows a user to edit the document as if they're co-authoring with themselves.

So, in addition to the obvious benefits for multi-user editing that come with real-time co-authoring, co-authoring in Office for the web provides benefits for single-user editing as well.

How co-authoring works in Office for the web

When multiple users edit a single document using Office for the web, the Office for the web service manages the document changes and any necessary merges internally.

When a user attempts to edit a document, Office for the web takes a lock using the Lock operation and the access token of the current user. When additional users then attempt to edit the same document, Office for the web will verify those users have permission to edit the document by calling CheckFileInfo using each user’s access token. If the CheckFileInfo call succeeds and the user has permissions to edit, they'll join the editing session already in progress.

Users who are collaborating then see the document content update in real-time as other users edit. But Office for the web only calls PutFile periodically with the updated document contents. There are three critical questions to consider in co-authoring sessions:

1. Auto-save frequency: How frequently does the application call PutFile?
2. PutFile access token: Which user’s access token is used when PutFile is called?
3. Permissions check frequency: How often does the application verify that a user still has appropriate permissions to edit the document?

Question 3 is important because PutFile is called using a single user’s access token, so a WOPI host is only able to check permissions of the user whose access token being used. Hosts rely on Office for the web to periodically verify that users still have edit permissions.

The answers to these questions differ between the Office for the web applications. The following table summarizes the behavior for each application, and the following sections describe the behavior in more detail.

Table 1 - Summary of co-authoring behavior for Office applications

Word for the web co-authoring behavior

Auto-save frequency: Every 30 seconds if document is updated. In other words, if users are actively editing a document, PutFile is called every 30 seconds. But if users stop editing for a period of time, Word Online doesn't call PutFile until document changes are made again.

PutFile access token: For each auto-save interval, Word for the web uses the access token of the user who made the most recent change to the document. In other words, if User A and B both make changes to the document within the same auto-save interval, but User B made the last change, Word for the web uses User B’s access token when calling PutFile. The file has both users’ changes, but the PutFile request uses User B’s access token.

But if User A made a change in one auto-save interval, and User B made a change in another auto-save interval, Word for the web makes two PutFile requests, each using the access token of the user who made the change.

Permissions check frequency: Word for the web verifies that a user has permissions by calling CheckFileInfo at least every five minutes while the user is in an active session.

Excel for the web co-authoring behavior

Auto-save frequency: Every two minutes.

PutFile access token: Excel for the web always uses the access token of the user who joined the editing session most recently. This user is called the principal user. If the principal user leaves the session, the last user who joined the session becomes the principal user. In other words, if User A starts editing, User A is the principal user. If User B then joins the session, User B becomes the principal user, and Excel for the web uses User B’s access token when calling PutFile. The file has both users' changes, but the PutFile request uses User B’s access token. If User C then joins the session, User C becomes the principal user.

If User C then leaves the session, User B becomes the principal user, and User B’s access token is used when calling PutFile.

Permissions check frequency: Excel for the web verifies that a user has permissions by calling RefreshLock at least every 15 minutes while the user is in an active session.

PowerPoint for the web co-authoring behavior

Auto-save frequency: Every 60 seconds if a document is updated. In other words, if users are actively editing a document, PutFile is called every 60 seconds. But if users stop editing for a period of time, PowerPoint for the web won't call PutFile until document changes are made again.

PutFile access token: For each auto-save interval, PowerPoint for the web uses the access token of the user who made the most recent change to the document. In other words, if User A and B both make changes to the document within the same auto-save interval, but User B made the last change, PowerPoint for the web uses User B’s access token when calling PutFile. The file has both users’ changes, but the PutFile request uses User B’s access token.

But if User A made a change in one auto-save interval, and User B made a change in another auto-save interval, PowerPoint for the web makes two PutFile requests, each using the access token of the user who made the change.

Permissions check frequency: PowerPoint for the web verifies that a user has permissions by calling CheckFileInfo at least every five minutes while the user is in an active session.

Scenarios

The following scenarios illustrate the behavior WOPI hosts can expect for each Office for the web application when users are co-authoring.

All scenarios described here assume the following baseline flow.

Scenario baseline

1. User A begins editing a document.
2. Office for the web calls CheckFileInfo using User A’s access token to verify the user has edit permissions.
3. Office for the web calls Lock using User A’s access token.
4. User B tries to edit the same document.
5. Office for the web calls CheckFileInfo using User B’s access token to verify the user has edit permissions.

Key points

• Office for the web always verifies that each user has appropriate edit permissions by calling CheckFileInfo using that user's access token before letting them join the edit session.
• Lock is always called using the access token of the first user to start editing the document.
• If users leave the editing session while others are still editing, Office for the web calls other lock-related operations, such as Unlock or RefreshLock, using the access tokens of other users that are still editing.

Scenario 1

1. User A continues editing the document.
2. User B makes no changes.

Table 2 - Co-authoring scenario 1

Scenario 2

1. User A continues editing the document.
2. User B also edits the document.

Table 3 - Co-authoring scenario 2

Scenario 3

1. User A leaves the editing session by closing the Office for the web application or navigating away.
2. User B continues editing the document.
3. User C tries to edit the same document.
4. Office for the web calls CheckFileInfo using User C’s access token to verify the user has edit permissions.

Table 4 - Co-authoring scenario 3

Scenario 4

1. User A continues editing the document.
2. User B is in the session but isn't editing the document.
3. While the editing session is in progress, User B’s permissions to edit the document are removed.

Table 5 - Co-authoring scenario 4

Scenario 5

1. User A continues editing the document.
2. User B also continues editing the document.
3. While the editing session is in progress, User B’s permissions to edit the document are removed.

Table 6 - Co-authoring scenario 5

Scenario 6

1. User A continues editing the document.
2. User B also continues editing the document.
3. While the editing session is in progress, User A’s permissions to edit the document are removed.

Table 7 - Co-authoring scenario 6