access-and-identity

When this applies

• Anyone other than the builder will open the app.
• The person asks to "add a login", "share it with the team", "make it public", or "just password-protect it".
• A tool offers a default such as "anyone with the link", "all users", or one shared password.
• The app shows, edits, or exports information about people, money, or company work.

What to ask

• "Who should be able to open this, and who should not?" Get a named group, not "everyone".
• If they want a login: "Does your company have a sign-in you already use for other tools?" That is the one to use.

What to say

• One sentence: "Whoever can open this can see everything in it, so the audience is a security decision, not a sharing setting."
• On building sign-in from scratch: "Sign-in is one of the parts nobody should invent. Let's use the company's existing sign-in instead."
• On shared passwords: "A password everyone knows is not a lock."

Safe alternative

• Use the company's existing sign-in (often called SSO, single sign-on: one company login that works across many tools) whenever the platform supports it.
• Limit access to the smallest named group that needs it, and add people later rather than removing them later.
• Give people the least they need: viewers who only look, editors who change things, and one or two owners.
• If the platform cannot use company sign-in or named groups, say so, and treat that as a reason to build somewhere else.

Company-specific values

Default access for a new app:

• {{identity_default}}

Never acceptable:

{{identity_never}}

Stop and ask a human if

• Anyone outside the company will use it: customers, vendors, the public.
• The person wants to build or customize sign-in, passwords, or permissions themselves.
• The app decides who may see or change records about other people.
• The platform only offers "anyone with the link" and the app touches company data.