Playbook, developer tools company
Access problems where half the accounts do not belong to anybody
Access on a developer product is not only about people. A large share of what authenticates is a process: a build agent, a scheduled job, a deployment step, each holding a credential that belongs to a team rather than to anyone. When one stops working nobody is locked out. A pipeline is red, and the message that arrives describes a failing job rather than a login screen.
Why this is not the general answer
The handling pattern for account access problems holds across every trade. What follows is the part that does not.
- The actor is frequently not a person, so the vocabulary of seats, invitations and forgotten passwords describes nothing about the problem, and an answer that uses it reads as though the question was never understood.
- Belonging to an organisation and being able to read a credential are separate permissions, so somebody can be fully joined, see the project, and still be unable to read the value they came for.
- Credential values are commonly displayed once at creation, which makes recovery impossible by design, and that has to be said in the first sentence rather than after a hopeful search through settings.
- Enforced company sign in is often sold on a higher tier, so an organisation that expected it and cannot find it is looking at a plan boundary rather than at a fault, which is a completely different conversation.
How it arrives
- our build job started getting 403 and nothing changed
- i joined the org but cannot see any of the credentials
- can you show me the value of a key we created last year
- how do we give a deploy step its own credential
- someone left and we do not know which tokens were theirs
- is enforced company sign in available on our tier
What has to be indexed for this to work
| The permission model, separating membership from credential visibility | What joining an organisation grants, which role may create, read and revoke a credential, and what a member without that role sees instead. Most of I cannot see anything is a role, and this table answers it in one line. |
|---|---|
| The credential lifecycle, from creation to retirement | What is shown at creation, what can be retrieved afterwards, whether a credential can be scoped narrowly, and how an old one is retired. State plainly that a value shown once is gone, because the hopeful search for it is where an afternoon disappears. |
| Guidance on credentials belonging to machines rather than to people | How to issue one owned by a project or a pipeline, and why an individual's credential should never be used for it. This is the page that answers somebody leaving and taking a nightly build down with them. |
| Which sign in and provisioning controls sit on which plan | Enforced company sign in, directory provisioning, session policy, each with the tier written against it. Two facts on one line, because a capability without its tier is not usable by anybody deciding what to buy. |
The reply
Being a member of an organisation and being able to read a credential are separate permissions, and the role table shows which role grants the second [1]. A credential value is displayed once when it is created and cannot be retrieved afterwards by anyone, including us, so where the value is lost the route is issuing a replacement and retiring the old one rather than recovery [2]. Where a pipeline authenticates, the documented practice is a credential owned by the project rather than by a person, which is also what stops a build failing the week somebody leaves. I cannot see your organisation, list what exists on it or issue anything, so leave your name, your work email and the organisation name if you need somebody to look.
It names the split between membership and visibility first, because that resolves the common case with no escalation at all. Saying the value cannot be retrieved by anyone, including the team, is more useful than a soft refusal, since it stops the reader asking the same thing in a different shape. The line about project owned credentials answers the question they will have next week.
Where it stops
The trigger. The reader asks for a credential to be issued or revoked, for a role to be changed, or asks which credentials or members exist on an organisation.
Issuing or revoking a credential and changing anybody's role both need somebody who can open the organisation, and I can do none of it. Leave your name, your work email and the organisation name, and it goes across with that attached.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never state that a credential exists, is valid or is still active, because nothing here can look one up.
- Never name or confirm who administers an organisation, or which people belong to it.
- Never suggest putting an individual's credential into a pipeline as a temporary measure.
- Never say a sign in or provisioning control is available on the reader's plan, since the plan is not visible from here.
Questions
- Can it tell somebody whether their credential is still valid?
- No, and this is the pair where the pull towards sounding authoritative is strongest, because everything else on a documentation site is precise. It can describe what a rejection looks like and what causes one. It cannot check anything, and a confident guess costs somebody a deployment window.
- People ask it to reissue a credential for a broken pipeline. What should it do?
- Say it cannot, name what does issue one, and take the details in the same message. A blocked pipeline is urgent, and the worst outcome is a sympathetic reply that leaves somebody waiting on something that is not happening.
- Is the machine credential guidance worth writing if we have not?
- It is the highest value page in this pair. Every organisation eventually loses a nightly job because it was authenticating as somebody who has left, and the page that would have prevented it takes an afternoon to write.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling account access problems in generalLocked out, wrong email, a colleague who left, no admin remaining. Identity cannot be checked in a widget, so explain, collect, hand over.
- The word reset covers two things here and one of them cannot waitRotating a credential without dropping traffic, and the first move when a token turns up in a public commit. Neither is a password reset.
- Cancelling ends the commercial edition, not necessarily the softwareAnnual terms, a credential that stops authenticating on a date, and an open source core somebody keeps running. What can honestly be stated.
- The units were consumed, and the customer still wants the money backOverage on units that were genuinely delivered is not a billing error. What can be explained about caps, and why a person decides the rest.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.