When multiple departments or external partners use the same app, you don’t want everyone seeing every option in your drop-downs. A marketing manager shouldn’t see engineering project codes, and contractors shouldn’t access internal employee resources. Smart drop-down filtering based on user identity solves this automatically.
In private apps, drop-down options can adapt to who’s signed in, showing only what’s relevant to their role or organization. This goes beyond filtering based on user selections (covered here) — the app knows who the user is and adjusts accordingly.
Filtering by role
User roles are typically managed through tags assigned to each person when they’re granted app access. For our project management example, let’s say users have either Employee or Contractor tags.
Consider this project resource table, stored in a hidden form screen named ProjectResources and created using our data editor:
| ResourceName | Category | AccessRole |
|---|---|---|
| Customer Database Access | Data Systems | Employee |
| Internal Wiki | Documentation | Employee |
| Project Asset Library | Shared Resources | Contractor |
| Contractor Guidelines | Documentation | Contractor |
| Shared Calendar | Scheduling | Employee |
| Public Templates | Shared Resources | Contractor |
To display only the resources available to the signed-in user, associate this formula with the Values property:
The FILTER function returns a subset of the ResourceName column based on a logical test. For each row, USERHASTAG checks if the signed-in user has the tag specified in the AccessRole column. When TRUE, that resource name appears in the drop-down. When FALSE, it’s excluded.
Employees see “Customer Database Access,” “Internal Wiki” and “Shared Calendar,” while contractors see “Project Asset Library,” “Contractor Guidelines” and “Public Templates.”
Filtering by company
If you don’t use role tags, company affiliation works just as well. Many organizations identify users by their email domain, automatically determining which company they represent.
Here’s a client project table stored in a form screen named ClientProjects:
| ProjectName | ProjectType | ClientDomain |
|---|---|---|
| Website Redesign Q1 | Design | acmecorp.com |
| Mobile App Development | Development | acmecorp.com |
| Brand Guidelines Update | Strategy | techstartup.io |
| E-commerce Platform | Development | techstartup.io |
| Marketing Automation | Strategy | globalmfg.com |
| Supply Chain Dashboard | Analytics | globalmfg.com |
To show only projects relevant to the user’s company, use this formula:
This works similarly to role-based filtering. The ENDSWITH function checks if the user’s email address ends with “@” plus the domain from the ClientDomain column. Users from acmecorp.com see only their website and mobile projects, while techstartup.io users see their brand and e-commerce work.
This approach eliminates the need to manually assign company tags — the system determines affiliation automatically from email addresses, reducing administrative overhead while maintaining strict access control.
Note: This technique requires named values, which are not available in our Starter plans.