Skip to main content

​
Customer portal

The portal is where your customers sign in. It uses a separate login system from your builder account. Anytime real users (not builders) should open pages, forms, or chat, configure chrome and navigation before invites so Preview matches what they will see. Set App Settings → Appearance → Portal chrome (Drawer or Tabs). Drawer (sidebar) is the default on phones; Tabs uses brand header + bottom tabs from your navigation tree, including pages inside groups. On phones, AI chat opens from the top bar next to Search. Account tools (Work, My Chats, My Files, My Memories, People, Usage, and the rest that apply to the role) live under More in the drawer, or in the profile menu in Tabs. See Navigation. Describe the portal experience in outcomes: clients land on Status, not staff tools; profile and log out stay in the header menu. GenieForge maps chrome and navigation. Preview as each customer role (Published before go-live). Confirm nav, pages, chat, My Chats, My Files, and Search (Command-K) match the role (open More in the drawer, or the profile menu in Tabs). Optionally open Preview with app presentation mode so the builder toolbar is hidden (see Preview as). If a role has Required steps, Preview as that role to confirm the first-login or waiver gate before you invite people. Customers should not redesign the app from the portal; building stays in Build mode for collaborators. You can put a project on a custom domain so the portal opens on your brand. If the project does not allow public join, the login page still shows a generic Sign in to your account form so existing members can sign in. It does not show the project name or a Join project link. People you invited use their invite link. Self-registered accounts must verify their email before they can sign in (see Inviting and managing end users). When more than one language is on under App Settings → Appearance → Languages, people pick a language from the account menu (and on login). Pages, Work, and the rest of the portal chrome follow that choice. See Languages.

​
Billing in the portal

When an app uses project-funded credits with tenant billing enabled, the workspace Owner sees a Billing item in the portal. From there they can:
  • Subscribe to a plan
  • Open Manage billing (secure billing portal) to update the payment method, change plans, or cancel
  • Add credits once the subscription is active
  • Configure auto top-up (charges pause if the subscription is not active)
Plan changes after the first subscribe go through Manage billing, not a second Checkout. Preview / synthetic users cannot open live billing. Admin and other roles do not manage billing; only the workspace Owner can. On HIPAA-enabled apps, workspace billing is payment-only. Stripe receives what is needed to take payment (not customer names, plan names or descriptions, or health information). The portal still shows the plan names you configured. The app owner acknowledges this in App Settings → Billing before billing can be turned on. Your GenieForge builder account billing (plans and seat credits) is separate from this portal workspace billing. See Billing, plans, and credits for the builder account side.

​
People in the portal

When this project has a workspace Owner (App Registration always assigns Owner), that person sees People in the portal. From there they can:
  • Invite staff by email and role
  • Change someone’s role
  • See last seen
  • Search the team by name or email
  • Remove someone from the workspace (their records stay)
  • Revoke or resend pending invites
  • Transfer ownership of the workspace (to an active member already in the workspace), choosing the staff role they step down to
A role change or a removal ends that person’s portal session, so they sign in again with whatever access they have now. Builder End-Users still covers impersonation, MFA reset, and delete all data. Usage in the portal stays identity-stripped (role and last seen only). People is the identified directory for the workspace owner of their own project.

​
Work in the portal

Work is off until you grant it to a role. Not every app needs a queue. Ask Building to turn on Work for the roles that should see it. Then those people open Work from More (drawer) or the profile menu (tabs) and see items assigned to them or their role: open or done, with an optional due date. Tapping an item can open the related page. Notifications stay a ping. Work is the inbox they return to. Owner and Admin do not get Work just because they have full tool access. Grant it the same way you grant a named extra. Guests and Preview users cannot be assigned work, and Preview cannot mark real items done. Pages, automations, and the in-app AI can put items on that queue for roles that have Work.

​
Activity in the portal

The workspace Owner also sees Activity: who viewed or changed records in this workspace. Opening a record (a peek drawer or a record page such as a client profile), and creating, updating, or deleting one, shows up here. A bulk change also appears as one line with the number of records, and each record still has History. Field values and row titles are not stored. Preview sessions stay out of this list. Clicking around pages without opening a record does not appear here; that is Usage. You can grant Activity to a custom role, or add it for Admin in one project, from Building chat. Admin does not see Activity just because they have full tool access. Export downloads a CSV of the same ids and slugs. When you open a record in a drawer, a History section can appear if you have Activity access.