You run one TestRail-class case repository for many teams. How would you decide where the permission boundary sits, and who is allowed to close a cycle?
answer
- a working tool and a record at once
- the project is the unit people own
- closing publishes, so name its owner
- too narrow and they share a login
basics
~10 sPut the boundary at the project, because that is the unit teams already own: read wide, author and record narrow, close-cycle held by a named human. Then defend it against drift toward everyone-administrator.
solid answer
~50 sThe repository is a working tool and a record at the same time, and those pull opposite ways, so the model is a position rather than a correct answer. My default puts the boundary at the project, since that is the unit that already has an owner: read wide, authoring narrowed to the project's own team, recording done by a dedicated account per pipeline, and close-cycle held by a named human who owns what the closed numbers assert. Organisation-wide capability is reserved for work that genuinely spans projects, each on its own account. Then I plan for the two failure directions: drift wide, countered by a narrow default at onboarding and a reviewed elevation list; and too narrow, which produces shared logins — wide reach with no attribution, and worse than the role you were avoiding.
go deeper
Know that permissions in a shared repository are set per project and that closing a cycle is a deliberate act with an owner, not routine tidying anyone does at the end of a run.
Explain why authoring is narrowed to the owning team while reading is usually left wide, and what an automated close would do to a cycle whose run was partial or retried.
Describe how you would audit a drifted installation: who holds the widest preset today, how they got it, and how you would take it back without stopping the work it was granted to unblock.
Argue the tension explicitly — friction against trustworthiness of the record — name the failure in both directions, and say what you accept rather than enforce when the product cannot express your model.
## A case repository is two products at once The reason this is a judgement call rather than a lookup is that one system is serving two purposes that pull in opposite directions. - As a **working tool**, it wants low friction. A tester mid-pass who cannot add a missing case, or fix a step that is plainly wrong, stops and asks someone — and the cost of that lands every day, on everyone. - As a **record**, it wants restricted writes. Release conversations, audit questions and regression arguments all rest on the repository being an accurate statement of what was tested and what happened. Any permission model is a position on that tension. There is no arrangement that is simply correct, which is why the interesting part of the answer is what you optimise for and what you accept. ## Put the boundary where ownership already is The workable default is to make the **project** the unit, because it is the unit teams already own, already name, and already have someone accountable for. - **Read**: wide. Cross-team visibility into what is being tested is usually a benefit, not a risk worth spending friction on — with the caveat that inventories carrying customer data or environment detail deserve a narrower default. - **Author**: narrow to the project's own team. Definitions are shared objects that other teams' records point at, so an edit made helpfully by an outsider is indistinguishable from an edit made in error. - **Record a result**: narrow, and for automation give it to a dedicated account per pipeline rather than to people or to one shared credential. - **Close a cycle**: a named human per project. - **Organisation-wide capability**: reserved for the small set of work that genuinely spans projects, each on its own account. ## Who closes a cycle Closing is the moment working data becomes a claim other people act on, so the capability belongs to the person accountable for that claim — ordinarily the project's test owner or release owner, by name. Two arrangements to reject explicitly: 1. **The pipeline closes it.** An automated close will end a cycle on a partial run, a retry or an early failure, and it leaves no person answerable for what the closed cycle asserts. 2. **Everyone can close it.** Then closing is housekeeping performed by whoever finishes last, and the numbers reported upward have no owner at all. This is the commonest arrangement and the one people defend hardest, because nothing appears to go wrong until somebody senior asks who signed off. ## The two directions the model fails | Failure | What it looks like | What it costs | |---|---|---| | Drift wide | Half the organisation ends up with an administrator-level preset | Nothing is enforced; the record is trusted anyway | | Too narrow | People share one privileged login to get routine work done | Wide reach plus no attribution — worse than a wide role | **Drift wide** is the familiar one. It happens one urgent Friday at a time: a push fails, the fastest unblock is a broad preset, and nothing ever removes it. The counters are structural rather than exhortative — make the narrow role the default at onboarding so nobody has to ask for less, make elevation temporary by construction rather than by intention, and review the widest role's membership on a schedule with a named owner and a date. **Too narrow** is the failure people underrate. A model nobody can work inside does not produce compliance; it produces workarounds, and the workaround is a shared login. That is strictly worse than the slightly wide role you were avoiding, because you now have broad capability *and* no idea who used it. When you tighten a model, watch for shared credentials appearing as the symptom. ## When the product will not express your model Frequently the model you designed cannot be configured: the product ships coarse presets, custom roles are unavailable, and the narrowest preset that lets a group work also lets it author. Then the control moves from prevention to detection, and the honest response has three parts: 1. Choose the narrowest preset each group can actually work inside. 2. Instrument the surplus capability — for example, alert on definition edits attributed to an account that exists only to report. 3. **Write down which capability you are accepting rather than enforcing**, so it reads as a decision in a year rather than as an oversight. The last point is what separates a designed model from an inherited one. A permission model that nobody can explain the reasoning behind gets widened by the next person under pressure, and the widening is never reviewed because there was never anything written to review it against.
- Your product only ships coarse presets, so the model you designed cannot be configured. What changes?The control moves from prevention to detection. Pick the narrowest preset each group can genuinely work inside, then instrument what the surplus capability allows — alert on definition edits from an account that exists only to report — and review the wide role's membership on a fixed cadence. Write down which capability you are accepting rather than enforcing, so it reads as a decision later instead of an oversight.
- How do you keep the model from drifting wide over its first year?Make the narrow role the default at onboarding so nobody has to ask for less, make elevation temporary by construction rather than by intention, and review the widest role's membership on a schedule with a named owner and a date. Most drift is one urgent elevation that nobody removed; the review is the only thing that removes it, and it happens only if somebody owns it.
saying these in an interview costs you the question
- Designs a model nobody can work inside, so people share logins
- Lets whoever finishes last close the cycle
- Treats an organisation-wide administrator preset as a convenience
- Sets the model once and never reviews the wide role's membership
- Cannot say which capability is accepted rather than enforced