Skip to main content

​
Shared tables

Most app tables live in one project. Shared tables are the exception: a person-owned row (training history, a profile that should travel) can be visible in another project after you grant access. Invoices, notes, and other tenant-private records stay in the project database. GenieForge staff enables this on the app. It needs platform Postgres for every project of the app. It is not available on HIPAA apps.

​
Where it lives

  • In Build mode, ask the AI to declare a shared table and set who owns the rows: the person, this project, or the whole app.
  • Grants are available in Chat and Build. The person must already belong to this project. A grant only covers rows that person created in this project, not rows they created in other projects.
  • Shared tables have one copy, not a draft copy and a published copy. Adding a shared table, adding a column, or renaming one takes effect right away for everyone, including portal users. Removing structure (dropping a table or a column, or narrowing a column) waits for Publish, so nobody hits a missing table mid-session.
  • Because a rename takes effect right away, the published app and portal keep looking for the old name until you Publish. Publish soon after renaming a shared table or column.
  • Search in the portal does not list shared-table records. Build pages that need those rows as tool pages, not table pages.

​
How to verify

  1. Confirm GenieForge staff has enabled shared tables on this app. If Building cannot declare one, email support@genieforge.ai.
  2. In Build, declare a shared table, then Preview in this project.
  3. Grant the person access from a project they belong to, then confirm that project only sees rows they created there.
  4. Publish, then confirm Published Preview and the portal see the same shared tables Build does.

​
Limits and notes

  • Project tables do not need a workspace key: the project already isolates its data. If Build refuses a new project table because it includes owner_user_id or workspace_key, those names are reserved for shared tables. Drop them and keep the table in this project (use user_id or end_user_id when a row belongs to a person), or ask Build to declare a shared table instead.
  • Membership is checked when you create the grant. Removing that person from the project later does not end it, so set an end date or revoke the grant when access should stop.
  • Shared tables are not available in throwaway eval or capability-test sessions.
  • Preview as a person can read shared tables and write person-owned shared rows. Those person-owned rows are real, and Reset in the Preview toolbar clears them (and ends their grants). Preview and Building cannot write project-owned or app-owned shared tables, because those rows are live and Reset would not undo them. If anything cannot be cleared, the reset says what was left for review instead of reporting a clean slate.
  • Seed data stays per project. Do not seed shared tables from project starter data.
  • Delete all data on a person removes their person-owned shared rows and ends their grants. Project- or app-owned shared rows that point at that person are listed for review instead of being deleted. Who owns a shared row is fixed when you declare the table; you cannot change that owner column later in Build.
  • Export/import carries shared table structure, not grants or live shared rows.
  • Turning on HIPAA later is blocked while shared tables or grants still exist.