Chapter 7
Administering a team
The things you set up once: projects and their history, people and their roles, keys, the audit trail, and billing.
5 sections · Chapter 7 of 8
Everything so far has been about doing the work. This chapter is about the scaffolding around it: who can see what, how machines authenticate, what gets recorded, and what it costs.
It all lives in the web dashboard, and most of it you will touch once when you set the team up and then only when somebody joins or leaves. That is deliberate — administration that needs constant attention is administration nobody does.
In this chapter
- 7.1Projects, files, and history on the webBrowse what is committed, see who has what locked, and read any commit, from a browser.
- 7.2Members, roles, and accessThree organization roles, plus per-project membership on top of them.
- 7.3Project keysHow the desktop app and the API authenticate, why keys are locked to a device, and how to rotate one.
- 7.4The audit logWho did what, when: commits, uploads, downloads, access, and membership changes. Studio and above.
- 7.5Billing and plansPer seat, monthly or annual, with tax handled at checkout and a portal you control.
Summary
Access is two layers: an organization role for what you can administer, and project membership for what you can open. That is what keeps an unannounced title safe in the same organization as everything else.
Keys are per project, hashed, and locked to the first machine that uses them, which makes a leaked key useless. Revoking one never touches any files.
Seats follow your member count, downgrades never delete anything, and the audit log is there on Team for the day a publisher asks.
One chapter left: connecting USourceControl to everything else you run.