User accounts and sign-in

Most useful apps know who is looking at them. Sign-in gives every person their own view and their own data.

Adding sign-in

Ask for it in plain language: "members should sign in with email and a password, and see only their own bookings." The builder adds sign-in screens, a session, and the checks that stop people seeing each other's records.

Common options include email and password, social sign-in providers and magic links. Ask which methods are available for your project; email and password plus one provider covers most cases.

The three parts of an account

• Authentication: proving who someone is.
• Profile: their name, photo and contact details.
• Authorisation: what they are allowed to see and do.

Beginners often build the first and forget the third. Decide the permissions early and write them down in a sentence per role.

A pattern that works

Visitors can create an enquiry but see nothing else.
Signed-in customers see only their own enquiries.
Staff see all enquiries and can change their status.

Then ask the builder to apply exactly that. It will add the rules to both the interface and the data layer, so a hidden button is not the only protection.

Testing it properly

Sign in as each role in a private window, and try to open another person's record by changing the address in the browser. If that works, the rule is missing. See Testing your app.

Password resets

Password reset emails need a sender. If you have not set one up yet, see Sending email.