💬 Ask your AI to set this up Paste this into your app's chat, replacing the example page names:
“Add sign-up, sign-in and sign-out using Overskill's built-in sign-in. Keep Home public. Require sign-in for Dashboard and Settings. Each ordinary user should read and change only their own private records; describe any staff access separately. Use the sign-in methods available for this app and handle email confirmation, recovery and an expired session clearly. If something is unavailable or needs manual setup, tell me instead of claiming it is complete.”
Review the preview and test the journey below. Publish the changes before expecting the live app to use them.
Which account do your users use?
Apps using Overskill's built-in sign-in use a shared Overskill account with access recorded separately for each app. A returning user can reuse their existing account; they do not need a different password for every app you build.
Creating an account and signing in are free. Your users do not need a paid creator plan just to sign in. Paid access or features you configure for your app are separate. Signing in identifies the person; it does not automatically grant every role, page or record. See Do your users need an Overskill account? for the account and payment distinction.
What a new user sees
The screens depend on your app's setup and the person's existing account:
- They open your app and choose a page or action that requires sign-in.
- They follow the sign-in or sign-up screen using an available method. Someone with an existing account should reuse it.
- If email confirmation is required, they open their inbox and follow the confirmation instructions. Submitting a signup is not always a completed sign-in.
- They return to the app with the access their account is allowed. Some entry paths show a separate permission screen naming the app and the information it requests; others include consent in the signup flow.
Check which sign-in methods your app actually offers before advertising a social sign-in button. Use the recovery option offered by the sign-in screen if someone cannot access their account.
Returning users and expired sessions
An existing session can make returning easier, but sessions can expire. The user may need to sign in again after an expiry, access change or browser-data reset. Another browser may also require a new sign-in.
Have returning users sign in with the same account they used before. If sign-in fails, show a clear message: it should not look like a successful load of an empty account.
Choose the pages and records to protect
Write down the access rules you need. For example, Home and a public product list can be public, while a customer's saved requests belong behind sign-in and are visible only to that customer and explicitly authorized staff.
A sign-in screen or hidden menu item does not prove these rules work. Check direct links to private pages and whether another account can read or change a private record. Ask the builder to enforce the same restrictions when records are loaded and saved.
Authorized workspace members can manage app-specific roles and access using the available app controls. Removing access to one app is different from deleting a shared Overskill account. Users should use account recovery themselves; app access management is not a way to reset another person's shared password.
Test before inviting customers
Use fictional records and two test users who are not the app's creator or workspace administrators.
| Check | Expected result |
|---|---|
| New signup | The user completes any required confirmation and reaches the intended app. |
| Existing account | The same account signs in without creating a duplicate identity. |
| Save and return | A saved record remains attached to the correct user after reload and a new sign-in. |
| Second user and signed-out visitor | Neither can read or change the first user's private record. |
| Sign-out and session expiry | Protected actions require a valid sign-in; failures do not pretend records disappeared. |
| Published app | The agreed checks pass on the live URL, including any custom domain you use. |
Record what happened and fix failed cases before inviting customers. The launch checklist covers mobile use, recovery and connected services too.
Explain what information your app collects and how people can ask for help. Shared sign-in does not decide your app's data-access rules or give you ownership of a person's account or information.