Help & Documentation

Collaboration runs on top of Cloud Sync. If sync isn't on, the project can only be edited on the device where it was created. You and every collaborator need:

• An account (free tier is fine). See the Cloud Sync topic for sign-up steps.
• An active internet connection while you're editing together. Offline edits still work; they just sync the next time you're online.
• A modern browser (Chrome, Firefox, Safari, or Edge). Mobile is supported, but mobile users will see narrower panels.

Sharing is per-project, not account-wide. Each project decides who can see it and at what level.

1. Open the project.
2. The collaboration controls live at the top of the project workspace — there is no separate drawer. Use the Collaborators card there.
3. If the project isn't shared yet, choose 'Enable collaboration' — this is the one-time migration from a local-only project to a shared one. Existing data is preserved.
4. Enter the email address of the person you want to invite. They need to have signed up with that same email — invites go to existing accounts.
5. Pick a role — the invite dropdown offers Editor or Viewer (the person who created the project is its only Owner; ownership cannot be handed over). See the next section for what each can do.
6. Send the invite. The other person sees the project in their dashboard on their next sync.

Three roles, each with a clear set of capabilities.

Owner

— The person who created the project. Owners can do everything — edit, invite others, change roles, disable collaboration and delete the project. There is no ownership transfer.

Editor

— Can add, edit, and remove items, categories, schedule and contacts, and can post comments and chat messages. Cannot delete the project, change other people's roles, or remove the owner. A posted comment cannot be edited or deleted by anyone, the owner included.

Viewer

— Read-only. Can browse the project, but every field is disabled and exports are blocked (exporting requires an editor role). Comments are visible; posting new ones is editor+.

Sharing a project used to share the project document only — Location, Call Sheets, Schedule, Crew and Requirements. The Pre-production tabs that keep their own records did not travel, so everybody saw only what they had typed themselves. They are shared now.

• Cast, Script, Scenes, Shot List, Episodes, Floor Plans and the markers on a floor plan are visible to every member of the project.
• There is ONE copy of each record. A collaborator with edit rights changes the project's cast member — not a private duplicate that never reaches you.
• A Viewer reads all of it and writes none of it. That is enforced on the server, so it holds even outside the app's own screens.
• Changes appear live, without a reload. If a message is missed — a background tab, a dropped connection — the tab catches up as soon as you focus it again.
• Only Pre-production and a linked Data Management project are shared. Invoices, expenses, contacts and bank data are not on the list and are never included.
• When someone loses access to the project, their local copy of its Pre-production records goes with it on their next session.
• A Data Management project linked to the shared project is shared too: its shooting days, transfers, offloads and verifications, with the same roles. Folder templates stay with each account, but each shooting day keeps a copy of the template picked for it, so teammates can open its cards. A change the server refuses (viewer, removed member, unlinked data project) is replaced by the server's copy; unsynced work is kept in a private “… (recovered)” data project when you lose access.

Once two or more people are in the same project at the same time, you can see each other working and your changes appear without anyone clicking Save.

• Avatars at the top of the project show who's currently online in this project.
• Coloured cursors show where each collaborator is focused — useful for deciding what to work on without overlap.
• Each cursor carries that person's name. If they haven't set a display name in their profile, the label shows their email address instead, and reads "Unknown" only while neither has been resolved yet.
• All edits are saved automatically. There is no 'Save' button you can forget.
• The connection auto-recovers after sleep, idle time, or brief network drops — you don't need to refresh the page.
• If two people change the same field at exactly the same time, the field-level lock (next section) prevents the clash; if a true conflict slips through, it surfaces in the Conflict Resolver dialog (see Cloud Sync → Resolving conflicts).
• Your presence refreshes itself roughly every 25 seconds, so you stay visible to people who join the project later — not just to those who were already there when you arrived.

When a collaborator focuses an input, that one field is briefly claimed for them. You see a small '<name> is editing' badge next to the input (it reads 'You are editing' for your own locks, or 'Someone is editing' when the name is unknown) and your own keyboard/screen-reader announces it as disabled. The lock is released the moment they tab away.

• Locks are PER-FIELD on most editors — you can keep editing the same form, just not the exact same field.
• Locks are RULE-LEVEL inside the Auto-Gear rule editor — the whole modal is claimed on open and released on close, because the modal stages a draft and only commits on Save.
• Locked fields turn aria-disabled so keyboard navigation and screen readers announce the state.
• Committed values propagate to all open sessions within a couple of seconds. Badges clear automatically.

Concrete inventory of every editor wired to the field-lock stream. Anywhere outside this list does NOT show badges yet — use 'who's editing what' etiquette there.

• Project Info & Settings: project name, description, settings-tab fields.
• Schedule: period editor (dates, shoot-day window) and calendar exclusion settings.
• Camera Package editor: package name, camera, cage, monitor, wireless transmitter, FIZ motors (×4) and FIZ controllers (×4). Under 'Rig Power Source': battery plate and battery, the gimbal (whether picked under 'Gimbal Only' or added as a gimbal load under 'Standard Battery', where its 'Remove' button greys out too) and the ring grip with its power modules, battery plate and battery. Linked fields lock together (camera with cage, gimbal with every ring-grip field, battery with battery plate), so while a peer holds one, all of them are greyed out for you. The rest of the editor (distance sensor, battery hotswap, the power-source choice, …) has no field lock.
• Project Requirements — Delivery Specs: global delivery resolution, base frame rate, aspect ratio.
• Project Requirements — per-package Camera Specs: sensor mode, recording resolution, recording frame rate, codec, gamma and colour space.
• Project Requirements — the rest of a camera package: Rigging (scenarios, camera handle, viewfinder extension), Camera Support (the whole cascade — holding System Type or Body Rig disables every field they clear), Storage & Media (each media row's type / brand & capacity / quantity / notes, plus the hours-to-cover and spare-cards plan), Mattebox & Filter (the mattebox choice and each filter row), Monitoring (all four display surfaces — viewfinder, onboard, built-in monitor and video transmission — down to peaking, Zebra / False Color and the status-component overlays), and User Buttons (one lock per button type, covering its five slots). Every id carries the camera package, so editing A Cam never greys out B Cam.
• Project Requirements — global sections: Transportation locks as ONE field covering the whole vehicle list, because every control there rewrites the entire list in one write; Carts locks per cart row.
• Billing rental row (ItemCostRow): rentalOverride, purchaseCost, the insurance cluster (insuranceMode ↔ insuranceCost ↔ insurancePercent ↔ insuranceBase), and insuredValue.
• Insurance provider settings: enabled toggle, rate, estimated value — per-field on owned / rental / sub-rental providers.
• Auto-Gear rule editor: rule-level lock (Save button and Enabled toggle disable with a 'locked by other' notice).
• Call Sheets: General Info (title, mode, PDF language, dates, producer, director), Department Call Times editor, Location Detail editor.
• Pre-production → Location sub-tab: every editable scout field locks. The eight on the Overview (name, address, master location, status, INT/EXT, DAY/NIGHT, available dates, linked scenes), all 41 fields across Look & Feel, Access, Logistics, Departments, Technical, Environment, Contacts, Safety, Costs and Notes, plus the map pin and the photo grid. A peer editing one greys it out for you and names them; on the pickers and the photo grid the whole control goes read-only rather than a single box.

Field-level locking handles same-time edits to individual inputs. A coarser gate guards the whole project: when you open a project that is already open in another tab or on another device, a dialog asks how to proceed instead of letting two editing sessions race each other.

• 'Force Open Here' takes over editing in this tab immediately — the other tab loses the edit lock.
• 'View in Read-Only Mode' opens the project with editing disabled everywhere — every tab, from the gear list to Camera Logs, blocks changes until you take over.
• While in read-only mode, a banner at the top of the workspace reminds you why editing is off and offers 'Take over editing' to claim the lock without reopening the project.
• The read-only choice applies to that one project in that one tab — opening a different locked project shows its own dialog.
• It covers the workspace chrome too, not only the tabs: undo/redo, the export buttons, the project-lock toggle in the header and the 'Enable collaboration' action are all off while read-only is on.
• Read-only is enforced, not advisory: the workspace refuses every write to the project while it is on — the Budget panel and category names included — and tells you once when something tries.

Structured discussions you can attach to a project, separate from real-time chat. Threads are designed for decisions you want a record of.

• Use @mentions to nudge a specific collaborator.
• Comments are kept with the project — they sync the same way the rest of the project does.
• Comments are permanent: once posted, a comment cannot be edited or deleted — not by its author, not by the project owner. (Shot and scene comments in the Shot List are a separate system: those can be resolved, which strikes them through but likewise never deletes them.)

1. Open the project's General tab (the project-wide discussion lives there), or open any gear item to comment on that item.
2. Type your message in the 'Add a comment' box.
3. Click 'Post comment'.
4. Other collaborators post into the same thread — entries appear in the order they were written, as one flat list. There are no per-comment replies, so quote or @mention whoever you are answering.

The Activity Feed panel is the chronological record of who changed what in this project. Useful after returning from offline work, after a conflict, or before a shoot day to make sure nothing was changed by accident.

• Each entry shows: action (item added, edited, deleted; category renamed; member added; etc.), the field that changed when applicable, before/after values, who did it, and a timestamp.
• Versions created via the Version History feature show up here too.
• Entries are immutable — you can't edit history.
• Disabling collaboration or deleting the project deletes the activity feed and edit history for everyone.
• The feed loads incrementally so even long-running projects open quickly.

An in-project chat panel for quick coordination that doesn't need to live in a comment thread.

• Messages are visible to all collaborators on the project.
• Chat history is kept with the project — new collaborators see what came before. Disabling collaboration or deleting the project deletes it for everyone.
• Use chat for fast back-and-forth: 'Added the second body, can you check?'. Use comments for decisions you want a record of.

1. Click the floating Team Chat button at the bottom-right of the project to open the chat popup.
2. Type your message.
3. Press Enter to post.

Collaboration tolerates offline gaps. Your edits queue locally and sync when you're back online.

• Edits made offline are saved normally and queued in the outbox.
• When you reconnect, the outbox flushes to the cloud automatically.
• If a collaborator changed the same field while you were away, the Conflict Resolver dialog appears for those records (see Cloud Sync → Resolving conflicts).
• Comments and chat messages you write offline send when you're back — they don't reach collaborators while you're disconnected.

Some collaboration surfaces use approvals so a change doesn't take effect until someone with the right role signs off. The Approvals panel renders inline on the project's General tab.

• Each pending approval shows who proposed the change, what was changed, and what it changes.
• An approver (typically the project owner) accepts or rejects it.
• Approved changes are committed; rejected ones are dropped.
• Approvals aren't on for every field — they're scoped to surfaces where unilateral changes would be risky.