In this article
A product can cover the right task and still be a poor fit for the way your team delegates it. Include access boundaries in the initial requirements, rather than discovering them during rollout.
Separate three questions
First, is the product available for the project? Second, can the person open it? Third, what actions can that person take once inside? Those questions are related but not interchangeable. A procurement checklist that records only “user access” is too broad to tell you whether the workflow is suitable.
Cast & Crew’s Project Users FAQ describes a Project Admin function spanning Start+, Hours+, Studio+ and Reporting+. It also says crew members are managed through their respective onboarding workflows rather than appearing in that Project Users list. That scope is important. Do not assume a central project-user list is a complete inventory of every person associated with a production, or extend its stated coverage to every product in the wider portfolio.
Specify responsibilities before permissions
Describe the job before choosing the role label. “Reviews department time information” says more than “manager.” “Receives the final approved reporting output” is different from “builds reports from underlying data.” The distinction helps a vendor explain whether its available roles match the organization’s intended responsibilities.
For each responsibility, write the smallest set of objects and actions that make it possible. A reader may need to view a document without editing it. A reviewer may need to act on a defined queue without changing project configuration. An administrator may need to manage access without becoming the default approver for every business decision. These are evaluation questions, not claims about particular Cast & Crew permission names.
A compact requirements worksheet
- Role purpose: the business responsibility in one sentence.
- Objects: the project, record category or report involved.
- Actions: view, prepare, review, approve, administer or export.
- Boundary: what the person should not be able to do.
- Change owner: who can authorize a role change.
- Review point: when temporary access should be reconsidered.
Keep this worksheet free of real names and credentials during evaluation. It is a design artifact. Actual access changes belong to authorized administrators in the official system, using the organization’s approval process.
Test a negative case
A demonstration should not only show that an intended action succeeds. It should also show that an unrelated action is unavailable to the role being evaluated. With permission, ask for a fictional example where a person can perform their assigned task but cannot reach a broader set of records. The evaluator does not need to probe an account or work around controls; the vendor can explain and demonstrate the boundary in its own authorized environment.
Also ask how a role change is represented. A temporary absence, a new department assignment and a project wrap can each require a different administrative response. Avoid assuming that removing one role necessarily deletes the person’s account, erases history or revokes every other project relationship.
Keep evidence project-specific
A role shown in one project is not proof of every project’s configuration. Capture the scope of the demonstration and the product experience used. The New Experience FAQ describes role-dependent navigation; a missing application can be an access question rather than evidence that the product does not exist.
Connect these requirements to the integration boundary questions. An output moving between systems also needs a legitimate recipient. The demo plan provides a way to record what was actually demonstrated.
Sources and scope
Public sources checked October 25, 2026. Product descriptions are documented claims; evaluation methods and fictional examples are our analysis. No private deployment was tested.
- Cast & Crew Project Users FAQ: Project Admin access and the separate treatment of crew members.
- Cast & Crew New Experience FAQ: Shared navigation, project context and role-dependent application visibility.