Logging users in to your app

Buzzy supports a wide range of logging in and onboarding scenarios.

Login Action Types

Email direct login link (Passwordless Login)

Email the user a link that will log them in. Use this option to enable passwordless login to your app.

Login with email and password

Submits the credentials (email and password) for authentication. If successful, navigate to a specified screen.

Create password

Creates a new password for a user. Used when an account was created by an admin or when the user was passwordless and now upgrades to a password account.

Change password

Change the user’s password; requires the correct current password and a new password.

Email reset password link

Email the user a link to reset their password. Your app must have a Reset Password Screen defined. To define a Reset Password Screen, go to the Settings page and enter the name of your Reset Password Screen into the corresponding field. Please note, this action requires you to define a Confirmation Screen. A Confirmation Screen is the screen that the app navigates to while waiting for the user to complete an out-of-app action (e.g. clicking a link sent on email or sms). A Confirmation Screen should let the user know that the action was performed (e.g. the email or sms was sent) and that they need to complete the action as instructed.

Create account (with email verification)

Creates an account with an email and a password, then email the user a link to verify their email address.

Invite user

Sends a user’s email an invitation link that allows them to create an account.

Reset password

After a user clicks the Reset Password Link sent on email, this action is used to change their password and log them in.

Demo login (e.g for App Store approval)

Use this for providing access to Apple or Google app store reviewers to bypass the need to receive an email.

Logout

Logs the user out of all sessions (web, mobile, and testing (for developers))

Setting up a Login and Registration Flow

A login flow typically requires at least a login screen, and a login confirmation screen if passwordless logins are being used.

If your login flow also requires registration then a user registration screen, also with a confirmation, would be required as well. Typically there would also be post registration steps for accepting a license and going through some kind of onboarding flow.

Enabling Logins

Login is controlled by Buzzy apps by the Privacy setting. If the app is set to 'Private' a login is required and the user will need to be a assigned to have access to the app. If the Privacy is set to 'Unlisted' or 'Public', no login is required.

Buzzy AI Toolkit

The Figma Buzzy AI Toolkit has examples for each of the screens that would appear in a login flow. If you use the AI app generation in the Buzzy plugin, it will setup the login flow for you, and on publishing to Buzzy, you can test this flow by enabling login on the app.

AI-Generated Apps

All AI-generated apps are ready for logins to enabled: they have login and registration screens as well as license and onboarding screens; the screens are set up in the app settings, and a group has been created for registered users to be added to. All that needs to be done to enable this is to set the app privacy setting to Private, which will typically also already be set up unless you asked for the app to be anonymous in your prompt.

Login Flow Template

Besides the login flow in the AI toolkit, there is also a more comprehensive login demo available here: https://www.figma.com/community/file/1141010375005736952/buzzy-plugin-login-demo

Common Patterns for User Flows

When implementing user authentication in your Buzzy apps, there are several common patterns that can help you structure your application effectively. Here are two of the most frequently used patterns:

User Flow Pattern (Personal Data Pattern)

This pattern aligns with the Personal Data Pattern security model, where users primarily interact with their own data:

• When a user logs in, a User View filters by the current logged-in user to find their record

• Results View: If the user has an existing record, you can display their data including any subtables (like projects, tasks, etc.)

• No Results View: If the user doesn't have a record yet, this indicates they need to create one - typically through a form or set of onboarding screens

Implementation details:

• Set "Who Can View" to "Admins, Authors, Creators & Viewers Only" to allow controlled sharing

• Users can view other users' profiles when needed, but typically can't edit them

• Use the Viewers field to explicitly allow specific users to view records

• Create a view that filters by the current logged-in user (e.g., Current User = {Current User})

This pattern is used in many Buzzy templates, including:

• Chat App - Users create chats and primarily see their own conversations, but can participate in shared chats
• Locations Report App - Users submit location data with admin users able to see all reports
• Course Quiz App - Students take quizzes and see their own progress, while instructors can view all results

The key advantage of this pattern is that it automatically handles both new and returning users with a single view, simplifying your app's structure.

User Flow Pattern Diagram:
+----------------+
|   User Login   |
+-------+--------+
        |
        v
+----------------+
|    User View   |
| (Filter by     |
| Current User)  |
+-------+--------+
        |
        v
    +---+---+
    |       |
+---v---+   |   +---v---+
|  No   |   |   |Results|
|Results|   +-->|  View |
| View  |       |       |
+-------+       +-------+
(Onboarding)    (Show User Data)

Security: "Who Can View" set to "Admins, Authors, Creators & Viewers Only"
Users can view other profiles but typically can't edit them

Organizations Pattern (SaaS Application Pattern)

This pattern implements the SaaS Application Pattern security model for multi-tenant solutions:

• Users first onboard and sign up for a subscription

• Once subscribed, they can create an Organization and add users to it

• Adding users sends invite messages to new users

• When a new user clicks the invite link, they are onboarded to the organization

• Users are added to Buzzy Organization or Team structures, which control secure access to information

Implementation details:

• Create an Organization datatable with "Who Can View" set to "Admins, Authors, Creators & Viewers Only"

• Use sub-tables for organization-specific data

• The organization admin is the "Creator" and manages team membership

• Team members can be added as "Viewers" or using "Team Viewers" fields to control access through Buzzy Organization and Team objects

• Use hierarchical security with sub-tables to ensure data isolation between organizations

The AI Strategy Plan app demonstrates this pattern with:

1. Users signing up and creating organizations

2. Organizations having multiple team members

3. Each organization only seeing their own strategies

4. Team members only accessing their organization's data

Organizations Pattern Diagram:
+----------------+
| User Signup &  |
|  Subscription  |
+-------+--------+
        |
        v
+----------------+
|     Create     |
|  Organization  |
+-------+--------+
        |
        v
+----------------+     +----------------+
|   Add Team     |---->|    Buzzy      |
|   Members      |     | Organization & |
| (Send Invites) |     |  Team Objects  |
+-------+--------+     +----------------+
        |
        v
+----------------+
|   New User     |
|   Onboarding   |
| (via Invite)   |
+-------+--------+
        |
        v
+----------------+
|    REST API    |
|   Automation   |
+----------------+

Security: "Who Can View" set to "Admins, Authors, Creators & Viewers Only"
Team members added as "Viewers" or using "Team Viewers" fields

REST API Automation

Both patterns can be automated using the Buzzy REST API, allowing you to programmatically:

• Create organizations and teams

• Manage team membership

• Handle user invitations and onboarding

• Control access permissions

The AI Strategy Plan app demonstrates this automation capability, making it easier to scale your application as your user base grows.

For more detailed information on implementing security for these patterns, see the Security and Access Control documentation.