User preview panel

The User preview panel lets you preview your application as any authenticated user from your database. This is essential for testing user-specific content, role-based access, and personalized experiences without needing to sign in and out repeatedly.

What is the User preview panel?

The User preview panel is a dropdown menu in the editor that displays:

• The currently connected preview user (or "Not connected" if viewing as a guest)
• A search field to find specific users
• A list of users from your database that you can connect as
• A "Disconnect" button to return to guest preview mode

When you connect as a user, the editor preview updates to show your application exactly as that user would see it, including:

• User-specific data and content
• Role-based page access and restrictions
• Personalized UI elements
• User-specific workflows and logic

Opening the User preview panel

To open the User preview panel:

1. Open the Interface tab in the editor
2. Click the user preview button in the top toolbar (shows current user or "Not connected")
3. The dropdown panel opens with a list of available users

Connecting as a user

To preview your application as a specific user:

1. Click the user preview button in the toolbar
2. (Optional) Use the search field to find a specific user by name or email
3. Click on the user you want to connect as
4. The preview updates immediately to show the application from that user's perspective

The toolbar now displays the connected user's name, indicating you're previewing as that user.

What happens when you connect as a user

When you connect as a user in the preview:

• Authentication data updates — The auth data available in the binding window now contains that user's data (ID, email, roles, custom fields)
• User-specific data loads — Any data filtered by user ID or user roles loads for the connected user
• Middleware checks apply — APIs with middleware restrictions enforce rules based on the connected user's permissions

Disconnecting from a user

To return to guest preview mode (viewing as a non-authenticated user):

1. Click the user preview button in the toolbar
2. Click the Disconnect button at the bottom of the panel
3. The preview updates to show your application as an unauthenticated guest

TESTING BOTH STATES

Disconnecting is crucial for testing how your application behaves for both authenticated and unauthenticated visitors. Always test:

1. Not connected (disconnected) — Verify login flows, public pages, and redirects work correctly
2. Connected (as a user) — Verify authenticated content, role restrictions, and user-specific features work correctly

Common use cases

Testing role-based access

If you have different user roles (for example, Admin, Member, Guest):

1. Create test users in your database with different roles
2. Connect as each user type in the preview panel
3. Navigate through your app to verify:
   • Admins see admin-only pages and features
   • Members see member content but not admin features
   • Guests are redirected or see restricted access messages

Testing user-specific data

For applications where users see only their own data:

1. Create multiple test users with different data in your database
2. Connect as User A and verify they see only their data
3. Connect as User B and verify they see only their data
4. Disconnect and verify guests cannot see any user-specific data

Testing personalized experiences

For applications with user preferences or personalized content:

1. Create test users with different preferences or settings
2. Connect as each user to verify:
   • UI adapts to their preferences (theme, language, layout)
   • Personalized recommendations or content displays correctly
   • User-specific workflows execute as expected

Testing authentication flows

To test sign-in, sign-up, and password reset flows:

1. Start disconnected (guest mode)
2. Test the sign-up flow (creates a new user in your database)
3. Use the User preview panel to connect as the newly created user
4. Verify the post-signup experience (onboarding, welcome content)
5. Disconnect and test the sign-in flow

Best practices

Create dedicated test users

Create specific test users for development and testing purposes:

• Use clear naming — Name test users clearly (for example, test-admin@test.com, test-member@test.com)
• Cover all roles — Create at least one test user for each role in your application
• Populate with realistic data — Give test users realistic data to test data display and filtering
• Keep them separate — Mark or tag test users so they can be filtered out of analytics or production data

DO NOT USE REAL USER ACCOUNTS FOR TESTING

Never connect as real users from your production database for testing purposes. This could:

• Expose sensitive personal information
• Accidentally trigger workflows that affect real user data
• Violate privacy regulations (GDPR, CCPA, etc.)

Always use dedicated test accounts.

Test both authenticated and unauthenticated states

Always test your application in both states:

1. Guest/Disconnected — Verify public pages, sign-up/sign-in flows, and redirects for unauthenticated users
2. Connected as a user — Verify private pages, user-specific data, and role restrictions work correctly

Test edge cases

Use the User preview panel to test edge cases:

• New users with no data — Connect as a newly created user with empty data to ensure your app handles this gracefully
• Users with missing roles — Test what happens when a user has no role assigned (if roles are optional)
• Users with multiple roles — If your system supports multiple roles per user, test users with various role combinations
• Users with special characters — Test users with special characters in names or emails to ensure proper display and filtering

Combine with responsive preview

Use the User preview panel alongside responsive preview modes:

1. Connect as a user
2. Switch between desktop, tablet, and mobile breakpoints
3. Verify user-specific content displays correctly across all screen sizes

How it works technically

In the editor

When you connect as a user in the editor:

1. The editor fetches the user's data from your database
2. The currentUser variable is populated with that user's information
3. The preview iframe re-evaluates all bindings, conditions, and workflows
4. Any data fetches or API calls that depend on currentUser are re-executed
5. The preview updates to reflect the user's authenticated state

What's included in currentUser

The currentUser variable contains all fields from your authentication setup:

Field	Description	Example
id	User's unique identifier	"user_123abc"
email	User's email address	"john@example.com"
roles	Array of role identifiers	["admin", "member"]
Custom fields	Any additional user fields you've configured	name, avatar_url, subscription_tier

You can access these fields anywhere in your app using currentUser.email, currentUser.roles, etc.

Difference from real authentication

The User preview panel is a development tool and differs from real authentication in important ways:

User Preview Panel	Real Authentication
Editor only	Works in published app
No session created	Creates authenticated session
No workflows triggered	Triggers "On sign in" events
Resets on page refresh	Persists across sessions
No password required	Requires valid credentials
Preview only	Full functionality

ALWAYS TEST IN PREVIEW AND PRODUCTION

While the User preview panel is excellent for development, always test your authentication flows in preview mode (with real sign-in/sign-up actions) and in your published application to ensure everything works end-to-end.

Troubleshooting

User preview panel is not visible

If you don't see the User preview panel in your editor toolbar:

1. Check authentication setup — Verify you have authentication configured in Integrations → Authentication
2. Enable an authentication provider — At least one provider (Email/password, Google, etc.) must be enabled
3. Create users — You need at least one user in your database for the panel to appear

Users are not appearing in the list

If the User preview panel opens but shows no users:

1. Verify users exist — Check Data & API → Auth → Users tab to confirm users exist in your database
2. Check user table connection — Ensure your authentication provider is correctly connected to your user table
3. Refresh the editor — Sometimes a page refresh is needed after creating new users

Preview doesn't update after connecting

If connecting as a user doesn't update the preview:

1. Check bindings — Ensure your UI elements are actually bound to currentUser data
2. Verify role restrictions — If using role-based access, confirm the connected user has the necessary roles
3. Check workflows — Workflows that run "On page load" may need to be re-triggered (refresh the preview)
4. Inspect currentUser — Use the Variables panel to verify currentUser is populated correctly

Cannot find a specific user

If you can't find a user in the search:

1. Check the user's data — Verify the user has an email or identifier you can search for
2. Try searching by ID — If email isn't set, search for the user's ID
3. Check capitalization — While search is case-insensitive, try the exact spelling of the user's email or name
4. Verify user exists — Confirm the user exists in Data & API → Auth → Users

Frequently Asked Questions

Can I connect as a user in my published application?

No, the User preview panel is an editor-only development tool. Your published application uses real authentication flows where users sign in with their credentials.

To test as a user in your published app, you need to actually sign in using that user's real credentials (email/password, OAuth, etc.).

Does connecting as a user trigger "On sign in" workflows?

No, connecting as a user in the User preview panel does not trigger any authentication event triggers like "On sign in", "After sign up", or "On sign out". These only fire during real authentication flows.

If you need to test these workflows, use the actual sign-in actions in your preview (for example, Sign in with email workflow action).

Can I modify user data while connected as them?

Yes, any changes you make to data while connected as a user will persist in your database (if you're working with real data, not mock data). However, be careful when doing this with production data.

Best practice: Use dedicated test users and test databases for development to avoid accidentally modifying real user data.

What happens if I delete the user I'm connected as?

If you delete a user from your database while connected as them in the preview panel, the preview will show an error or behave as if the user is disconnected (guest mode). Simply disconnect and connect as a different user to continue testing.

Can I connect as multiple users at the same time?

No, you can only connect as one user at a time in the editor. If you need to test interactions between multiple users (for example, chat applications, collaborative features), you'll need to:

1. Open multiple browser tabs or windows with your published app
2. Sign in as different users in each tab
3. Test the interactions in the published environment

How do I test with users that have no email address?

Some SSO Providers (like phone number authentication) may create users without email addresses. To connect as these users:

1. Search by their user ID in the User preview panel
2. Or search by their phone number or username (if these fields are searchable)
3. The user list should still display these users with their available identifier (ID, phone, username)

Continue learning

• Managing users — Learn how to create and manage users in your database
• Managing roles — Set up role-based access control for your users
• Private pages — Restrict page access based on authentication and roles
• Authentication workflows — Implement sign-in, sign-up, and sign-out flows