Facilities intake: picking a project type that survives a legal audit
Meridian's Jira Cloud site has 340 users, 11 company-managed projects and 4 team-managed projects. The facilities team asks for a new project to receive maintenance requests from all staff. From the intake meeting: about 250 employees must be able to submit and comment but must not see one another's requests; the facilities lead, who holds Jira Product Admin rights but is not a site admin, wants to rename statuses and add one during a six-week pilot; after the pilot, legal requires that workflow edits be limited to site admins and that permissions match the existing LEGAL project exactly; two custom fields (Building, Asset ID) must share their options with the existing ASSET project. The team has no developer and wants the project live on Friday.
1. Which project type do you create, and how does each of the four requirements drive that choice?
Read the worked answer
Decision: company-managed project.
Map each requirement to the constraint that decides it:
- (a) Staff must not see one another's requests. That is issue-level visibility, which in Jira Cloud is only delivered by an issue security scheme - a company-managed capability. A team-managed project has no security levels, so the alternatives would be 250 separate projects or a portal that hides other people's requests by accident, neither of which meets the requirement.
- (b) The lead edits statuses without being a site admin. In a company-managed project a project administrator can edit a workflow only when that workflow is not shared with other projects. Give the project its own copy of a workflow and she can edit it; share it and she cannot.
- (c) 'Match LEGAL exactly.' That means reusing a permission scheme, which team-managed projects do not have.
- (d) Shared options for Building and Asset ID. One custom field with a context covering both projects - again company-managed.
Accepted cost: the lead gets less autonomy than a team-managed project and every structural change routes through admin-configured schemes. These are hard constraints, not preferences, so the autonomy is what gets traded away.
2. Give the build sequence, naming the object you create or change at each step.
Read the worked answer
- Create the project from a blank company-managed template, not a template that spawns its own schemes, so you explicitly control every association.
- Permission scheme: if legal means 'identical forever', share LEGAL's scheme; if it means 'identical at launch', clone it. Default to cloning - editing a shared scheme later mutates both projects silently, and facilities will inevitably want to diverge.
- Issue security scheme: one level, say 'Requesters and Facilities Agents', whose members are the special member Reporter plus group
facilities-agents; mark it the default level. Then grant Browse Projects broadly (all-staff group) - issue security filters visibility, it never grants it. - Custom field contexts: new contexts for Building and Asset ID containing the new project and ASSET. Do not add new options to the existing global context, or every project inherits them.
- Screens: a short create screen with only what a requester must supply; agent-facing screens separate.
- Workflow: a project-scoped copy. Grant Administer Projects to her group via the project role Administrators so she can edit statuses during the pilot.
- Board and filter for the facilities agents, then test end-to-end with one requester account and one agent account before Friday.
3. The pilot ends and you must lock workflow editing to site admins. What breaks, and what must you check first?
Read the worked answer
- Losing edit rights has a wider blast radius than it looks. Administer Projects is a single permission covering boards, versions, components and other project settings - remove it and she loses all of that, not just workflow editing. Decide explicitly which of those she keeps; if she must keep board configuration but not workflow editing, the answer is to keep Administer Projects and instead convert the workflow into a shared workflow, which alone removes her edit rights.
- Her pilot renames are now liabilities. Any status she renamed is referenced by board column mappings, saved filters (
status = "Waiting on Facilities"), dashboard gadgets, SLAs and automation rules. Before locking, freeze status names, then grep filters, dashboards and automation for the old names. - Statuses in use cannot be deleted from a workflow. Retiring one means moving issues off it first, not pressing Delete.
- Verify with the permission helper as a requester, an agent and the lead, and confirm the workflow is genuinely shared (or not) before telling legal it is locked.