Public Access
Public Acces let you share specific parts of your Noloco app with the world — no login required. Whether you're showcasing a course catalog, event listings, or a product directory, you stay in control
What is Public Access?
Public Access allow parts of your Noloco app to be accessed without a user logging in. You decide:
Which tables are visible
Which records and fields can be viewed
Which pages are public, private, or shared
This means you can create rich, read-only public content while still keeping sensitive or interactive features behind login.
Public Access is available on the Business and Enterprise plan.
How to Enable Public Access
You can configure public access in any app — new or existing — in just a few steps:
Open your app settings and select Public Access, or use this link: https://portals.noloco.io/~/_/settings/public-access
Click Setup to begin configuration (your app won’t go live yet).
Expand the table list to choose which tables should be available publicly.
Toggle public access on for selected tables.
Use the Permissions Panel to define exactly which fields and records are public. Learn more about permissions
In the Views Tab, choose which views are publicly visible. Learn more about visibility rules
Set your navbar pages to be Public, Shared (conditionally visible), or Private.
When ready, toggle the main switch to enable public access.
Click Review & Publish to finalize and make your app publicly accessible. Learn more about publishing
🔒 By default, everything is private. You have full control
Best Practices for Safe & Effective Public Access Apps
Expose only necessary fields. Don’t make entire tables visible unless needed.
Use a dedicated permission rule for public users. This avoids overlap with logged-in users.
Create public-specific views. These can simplify layouts and avoid confusion.
Default to read-only access. Only allow updates or submissions when absolutely required.
Security & Limitations
Public data is fully accessible without login, but you control what’s exposed.
Use field- and record-level permissions to ensure data safety.
Public views refresh less frequently than authenticated ones, which helps manage load.
Personalization (e.g. user-specific content) requires login and won’t work in public view.
Existing apps can be partially opened up — keep secure sections fully private.
Frequently Asked Questions about Public Access
Is my data safe if I enable Public Access?
Yes. Only the data you explicitly mark as public is exposed.
Can people see all of my tables and fields?
No — you control which are visible using permissions.
Can public users submit forms or edit records?
Yes, but only if you enable those features by defining specific permission rules for pubilc users
Can I personalize the app for each visitor?
Only for logged-in users. Public visitors see general content only.
Troubleshooting Public Access Issues
I turned on public access, but users still need to log in.
This is the most common public access issue. Check these items in order:
Main Toggle: Ensure the main public access switch is ON in Settings > Public Access
Page Settings: Verify affected pages are set to "Public" (not just "Shared")
Publishing: Click "Review & Publish" - public access changes require republishing
Table Permissions: Check that underlying tables have public permission rules set up
Domain/URL: Ensure you're accessing the correct published app URL
My data isn't showing on public views.
When public users can access pages but don't see data:
View Selection: Check that you've selected the views in the Views tab of public access settings
Permission Rules: Verify there's a permission rule that allows public users to READ the table
Field Permissions: Ensure the fields you want visible have READ permission for public users
Record Filters: Check if permission rules have filters that exclude all records for public users
Data Sync: Try manually syncing your data if using external data sources
Some fields are missing on public pages.
Missing fields usually indicate permission issues:
Field-Level Permissions: Review field-level permissions for public users
Required vs Optional: Check if missing fields are marked as required (may cause display issues)
Component Configuration: Verify the view/component is configured to show those fields
Field Types: Some field types may not display properly in public contexts
Public forms aren't working - users see login screen.
For public forms specifically:
Form Page Public: Set the form page itself to "Public" in page settings
Table Permissions: Create a permission rule allowing public users to CREATE records
Form Fields: Ensure all form fields have appropriate permissions (CREATE for required fields)
Publishing: Republish after making permission changes
Test Incognito: Always test public forms in an incognito browser window
Can I associate different policies to public forms for different user types?
Yes, you can create multiple permission rules for public access:
Multiple Permission Rules: Create separate rules for different scenarios (e.g., "Public Form A", "Public Form B")
Different Field Access: Each rule can grant access to different fields
Conditional Logic: Use custom filters in permission rules to control which records public users can create/access
Separate Apps: For completely different policies, consider creating separate public-facing apps
How do I troubleshoot conflicts between public visibility and permission rules?
When you're getting conflicting visibility notifications:
Check All Layers: Review page visibility, component visibility, and table permissions separately
Simplify First: Start with basic public access (no custom rules) and add complexity gradually
Test Incrementally: Make one change at a time and test in incognito mode
Clear Cache: Clear browser cache or test in different browsers
Review Logs: Check your app's access logs if available to see where requests are being blocked
Advanced Public Access Scenarios
Creating Separate Public Apps for Different User Types
To create separate public apps for trade vs client users:
Duplicate Your App: Create multiple Noloco apps connected to the same data source
Different Permission Rules: Set up distinct permission rules in each app
Separate Branding: Customize each app's appearance for different audiences
Different Data Views: Show different tables/fields in each app
Unique URLs: Each app gets its own public URL for different user groups
Testing Public Access Thoroughly
Incognito Browsing: Always test in incognito/private browser windows
Multiple Browsers: Test across different browsers and devices
Clear Cache: Clear browser cache between tests
Test All Flows: Test not just viewing, but form submission, navigation, etc.
Different Data States: Test with different data scenarios (empty tables, full tables, etc.)
Security Best Practices for Public Access
Minimum Necessary Access: Only expose fields and tables that absolutely need to be public
Regular Audits: Periodically review what's exposed to public users
Monitor Usage: Keep an eye on public access logs for unexpected usage patterns
Backup Strategy: Ensure you can quickly disable public access if needed
Data Validation: Implement strong validation on any publicly submitted forms
Last updated
Was this helpful?

