If a project has multiple editors—staff who update their own task completion percentages and extra hours worked, or site managers who track resource costs, for example—the need for collaborative features becomes evident. When stored in a shared server repository, multiple users can publish and subscribe to changes to a project, and the project’s administrator can review and accept or reject each change as it is made.

Likewise, if resources are shared between multiple projects simultaneously (staff working on Phase 1 of Project Alpha and Phase 3 of Project Beta concurrently), storing projects in the same repository allows resources with the same unique identifier to be leveled intelligently across all projects that include them.

If either of these scenarios apply to your project, the publication and subscription features of OmniPlan Pro repository sync are just what you need.

If you previously purchased the OmniPlan 3 for iOS Pro upgrade but haven’t yet installed it for this copy of OmniPlan (perhaps because it’s on a new device), choose Upgrade to Pro from OmniPlan Settings and tap Restore Purchases on the Pro Upgrade screen. And if you haven’t yet upgraded to Pro, this is the place to do it.

The process of creating and connecting to a server repository account is described in Multi-User Publication and Subscription (Pro) in the Getting Synced chapter, and the instructions there will help you get your first account up and running quickly (or connect to an existing one).

When you choose an existing project in a shared server repository, it is downloaded and copied to the Local Documents location in the Document Browser. It is available for editing just like any other OmniPlan project, with one important addition: it comes with its server repository settings pre-configured. The project is ready to publish its changes and receive updates from the server, and will by default publish changes to its resource loads and subscribe to those made in other projects on the server.

The next step describes connecting a new project to a shared server repository from scratch.

Next, choose a server account to sync with. Tap Repository to make the choice; if you have one set up (having just completed Step 1), you’ll see it listed here. If not, tap Manage Repositories and follow the instructions in the Getting Synced chapter to create an account.

When you choose a repository account for the project, it is copied to the server and is now ready to be published to the server for the first time.

Unlike OmniPlan’s OmniPresence sync and other cloud sync methods where the primary concern is keeping files in an identical state across your devices, publish and update actions don’t happen automatically when syncing to a shared repository.

This is by design—since the project is shared by multiple contributors, it’s important to monitor changes as they’re applied. User-invoked publication and updates provide a mechanism for more deliberate information exchange and detailed change tracking tools for administration of the project.

Once a project is published, a count of changes made since the previous publish action is displayed beneath the Publish and Update controls in the Project inspector.

At any time after connecting a project to a shared server repository, tap Publish & Subscribe in the Project inspector to edit its repository settings.

1. Repository—tap to select a different shared server for the project, manage repository accounts, or choose resource load publication settings.
2. Auto-Update Interval—tap to choose an interval at which the project will automatically receive new changes from the server. This is useful if the administration requirements of your project don’t involve gatekeeping of the changes made by others.
3. Active—tap to switch the project between active and inactive status. An inactive project saves its repository account information, but loses the ability to publish or update until it is made active again.

The settings for resource load publication and subscription can be be found in the Project inspector’s Publish & Subscribe screen under Repository.

Choosing to publish a project’s resource loads means that other subscribing projects will obey its workload information when leveling; if Julie is working on Project A on Wednesday and its loads are being published to Project B, after leveling Project B won’t schedule her to work on Wednesday.

Choosing to subscribe to resource loads means that the project will obey all constraints by projects in the repository that are publishing their loads. By using only the publish or subscribe option a hierarchy of priority can be established between simultaneous projects—a project that only publishes will always have its needs met first, while a project that only subscribes will be assigned resources only when they can be spared.

By both publishing and subscribing, projects are treated as equals—and if a project neither publishes or subscribes, it ignores external factors and syncs only with its own updated resource load information.

To enable change tracking, tap Change Tracking in the View inspector. A toggle switch appears to indicate that change tracking of the shared project is currently turned off; tap it and return to the View inspector to see that change tracking is now enabled.

From now on, whenever a change is made to the project (either locally or remotely), it will be logged in the Change Tracking screen in the View inspector. When a change is ready for review the View inspector’s icon changes to note that an approval action is required.

The Change Tracking screen displays a list of changes made since your last visit. Each change includes the relevant task name, the device responsible for the change, the date the change was made, and the nature of the change. In the example, the administrator’s iPhone was used at 4:04 PM today to add Task 1 to the project.

To manage changes, select them by tapping them individually or choosing to Select Local or Select All changes. With the desired changes selected, tap Accept to keep them applied, or Reject to revert the project to its state before the selected changes were made.