In a team task tracker, you may want members to see their own tasks while an app administrator manages the team. A visitor should not gain access just by finding the task list's address.
Access rules answer two questions: what may this person do, and which information may they do it to?
Your Appify builder account manages the project. An app account signs into the application you build. These are separate identities and sessions, even when they use the same email address.
The builder can receive an app administrator invitation, but the app account still needs its own activation and sign-in. Being an Appify platform administrator does not automatically grant access to an application's private records.
Current builder editing is owner-only. Sharing a workspace name or inviting someone into a generated app does not make that person a project co-editor.
The current application model uses administrators, members, and public visitor access where explicitly allowed. Broader custom roles remain future work.
For each table, review reading, creating, updating, and deleting separately. Also review the record scope: “own records” and “all records” produce different results. Assigning a task to someone does not, by itself, define a new access policy.
Fields and views have visibility rules too. A public task summary should not expose a members-only field through search, a linked view, or another route.
Removing a button does not revoke permission. Showing a button does not grant it. The application must check the current person's authority when it reads information or performs an action.
The same applies to saved filters and frontend names. A “My tasks” filter is a browsing convenience; a “Staff” frontend is an interface choice. Neither replaces record-level checks.
Preview and production have separate app accounts and sessions. Test with the intended audience and environment rather than assuming your builder session represents every user.