I work as an internal comms manager and I want to create an internal communications tool.
I want to create a option where a few admin users can chose what to communicate and to who based on HR data via CSV upload.
The CVS will contain all employees data: Name, Role, Manager, Manage Level (If applicable),Team, Function, Region and email addresses.
So some communications will be for all e.g. Project Managers (Role), some will be for all Managers (Manager), some will only be for e.g. Finance(Function) and some will have a mix and/or multiple e.g. Functions or Regions(e.g. Europe/ North America).
I have no clue where to start to build this?
Sorry I’m quite new to bubble, so I hope my question make sense?
First create some option sets to define fields such as function, level and region. After that, add them in the database table either in the user or some other user_sat that you create to improve management, so you will allow you to make filters to trigger the messages, whether this filters built only on a page through dropdown or pages pre-defined by you.
Hi,
Thanks for taking the time to answer, really appriacte it.
However, I’m not sure it answer what I’m asking.
This doesn’t tell me how to upload HR data as mentioned above and how to use the data to filter and choose between different levels, types, areas etc. for comms to be sent out.
When an admin creates a new communication, you can let them select Role, Manager, Function, Region, etc. - How do i set this up?
Then run a search on the User table to match those criteria and either store the list in the Communication entry or display it dynamically. - How do I do this?
Display communications:
Users log in and see a repeating group showing Communications filtered for them (based on matching Role, Function, etc.).
Could you please provide more in details information for this?
Instead of putting this on the role level, just add a list of permissions, you can then dynamically add/remove permissions per user role, or set a default list of permissions for a role to start with.
Imagine you have a big playground with different areas: the slide, the swings, the sandbox, and so on.
Roles = Types of Kids
A role is like saying “you are a big kid” or “you are a little kid.”
But just knowing someone is a big kid doesn’t automatically tell us exactly what they’re allowed to do.
Permissions = Playground Tickets
A permission is like a ticket that lets you use a specific area:
A “slide ticket”
A “swing ticket”
A “sandbox ticket”
You can give a kid as many tickets as you want, no matter their role.
Why this is better
Instead of saying:
“Big kids can always use the slide”
“Little kids can never use the swings”
You make a list of tickets (permissions) and decide:
What tickets each role should start with
What tickets each individual kid can gain or lose later
So:
A big kid role might start with slide + swings
A little kid role might start with sandbox
But if you want, you can still give a little kid a swings ticket, or take away a slide ticket from a big kid
In simple words
Instead of baking the rules into the role, you use permissions as attachable stickers.
Roles just tell you which stickers someone starts with.
After that, you can add or remove stickers anytime.
Wow thansk for taking all the time to give this great methapor.
But maybe I havent statet correctly what i need.
I don’t need to give specific users restrictions, as much as i need for an Internal Communication person to send out some comms depending on a selection of e.g. role, region, function, team in x function etc.
So say the person wants to send a message to all project managers across functions.
Or a message to multiple teams, expect one, in Finance.
Or all project managers in Finance.
Or everyone in North America.
How do i set that up in the database? and how do i give e.g. the internal comms manager the option to select first Function, then role (e.g. everyone in x function or project managers in x function etc.)
is it still permissions you would use?
This absolutely makes sense you’re describing a very realistic and common internal tool workflow in Bubble. I’ve built several systems for employee communication and targeted messaging just like this, so let me quickly break down the most robust way to structure it:
The Core Database Structure
Data Type: Employee
Fields:Name (text), Role (text), Manager (text), Manager_Level (number), Team (text), Function (text), Region (text), Email (text).
Pro-Tip: Uploading your initial CSV directly to this Data Type is the fastest way to populate it.
Data Type: Message
Fields:Title (text), Body (text), Created_By (User), and crucially, Targeted_Employees (list of Employee). This links the message directly to the audience.
The Targeted Messaging Page
Build the Admin Targeting Interface:
Admins use simple input elements (Dropdowns for Role, Team, Region, etc.) to set their filters.
A Repeating Group runs a Search for Employees and applies constraints dynamically:
Example Constraint:Role = Dropdown Role's value (Only when Dropdown Role is not empty).
This allows for powerful, stacked filtering (e.g., ‘All Managers in Finance who are in Europe’).
The “Send Message” Workflow:
When the admin confirms, the workflow must: a. Create a new Message entry. b. Set the Targeted_Employees field to the exact list of employees currently displayed in the filtered Repeating Group. c. Trigger the email distribution (using Bubble’s native Send Email action or a robust API service like SendGrid, looping through the Targeted_Employees).
Going Above and Beyond
For future scalability, you might consider:
Tracking read status for compliance/reporting.
Creating Quick-Filters (e.g., ‘All Management Team’, ‘Sales APAC’) to save admin time.
This is a pretty straightforward build, but getting the database links and filtering logic right from the start is key. If you’d like, I can help you validate the database structure and walk you through setting up the core targeting logic step-by-step.
Happy to dive deeper into this build with you. Hope this helps a bit to clarify on your issue and shade some light.
Hi Simon , totally understand, Let me simplify it for you so you can set it up correctly without needing Option Sets.
You don’t need an Option Set for this
Since your Employee data is already stored in the database (Role, Team, Region, etc.), your dropdowns should simply pull options directly from your Employee entries.
Here’s what to put in each dropdown
Type of choices: text
(This is because Role, Team, Region are all text fields in your Employee data type.)
Choices source:
Search for Employees:grouped by Role
or whichever field you want (Team, Region, Function, etc.)
Option caption:
Current option’s Role
(or Team, Region, etc.)
This gives you a unique list of available Roles/Teams straight from your data
no Option Sets needed.
How the filtering ties together
Once the dropdowns are set, your Repeating Group should do:
Search for Employees
with constraints like:
Role = Dropdown Role’s value (only when Dropdown Role’s value is not empty)
Team = Dropdown Team’s value (only when Dropdown Team’s value is not empty)
Region = Dropdown Region’s value (only when Dropdown Region’s value is not empty
This allows you to stack filters automatically.it’s just one or two clicks once it’s clear.
