Define end-user permissions before generating screens, and keep them separate from the roles used to collaborate on the project. A person who can edit a builder project is not automatically an administrator of the resulting application.
Distinguish the two permission systems
Lovable documents project sharing with workspace members or external collaborators through roles including Admin, Editor and Viewer. Role availability and external-collaborator controls vary by plan and workspace settings.
That evidence concerns project collaboration. It does not establish your application's customer, operator or manager permissions. Practical editorial advice: give those application roles their own specification, tests and owner.
For example, the developer of an Indian booking service may need project-editing access without needing routine access to bookings. Treat that separation as a design question rather than inheriting powers from similar role names.
Write the authorization matrix as records
For each application role, record resource, action, ownership condition, allowed fields and expected denial. Use explicit denials for unresolved cases.
A hypothetical repair-booking application could start with:
- Customer: create a booking; view own bookings; cancel own unassigned booking; deny access to another customer's booking.
- Technician: view assigned jobs; update job progress; deny reassignment and changes to the quoted amount.
- Dispatcher: assign jobs within the specified service branch; deny access outside that branch.
- Signed-out visitor: view public service descriptions; deny booking-history access.
These are illustrative requirements, not a built-in role model. Add separate decisions for exports, bulk edits, attachments and role changes; they should not inherit permission merely because a screen contains a convenient button.
Test ownership as well as role
Use synthetic actors Customer A and Customer B, with bookings A-101 and B-202. Customer A should be allowed to retrieve A-101 and denied B-202 under this example policy.
Evaluate direct resource requests as well as screen visibility. Hiding a button is not adequate evidence that the protected operation is denied. Record the actor, action, target record, expected decision and observed result without including credentials.
Also test a technician whose assignment has been removed. The expected result should follow the current approved policy, not the fact that a page was previously open.
Gate generation and release differently
Before screen generation, stop when resource ownership or role boundaries are unresolved. Before release, stop when a denied operation succeeds at the processing boundary. Next, correct enforcement and rerun both permitted and denied cases.
If buying collaboration access, check the coding catalog for access format and saved terms. Marketplace account/code/token offers are not proof of official subscription equivalence or identical collaborator controls.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Lovable project sharing establishes role-based project collaboration and its plan/settings qualifications. The end-user matrix and tests are editorial requirements, not documented Lovable application authorization features.