Privacy Rules with user-controlled boolean - how to do it properly?

Need help Database
1

I’m building an e-Cv builder app for people to share their CV’s online that’ll make them look nice and comfortable reading on any devices.

What I’d like to achieve:
Have 4 types of personal data I’d like users to be able to make public or private with a simple toggle.

The fields in question, just to make referring easier: email, mobile number, landline and address.

How I tried it so far:

  • I was first trying to make the toggle simply “delete” data from the corresponding field, but it can create user-side frustration especially in accidental missclicks
  • Added all data types to the “CV” table + 4 Booleans called “email on”, “mobile on” - and so on.
  • Tried to set rules like on the attached photo, but it feels like that rules are interfering with each other.
  • I was thinking to create 16 rules for all scenarios (if mobile off and if landline on and…) kind of thing, but it’d take forever and I’ll create unforeseen amount of errors, for sure

There has to be a better way, I just need to find it somehow!

Any ideas where to look for?

image
image1299×942 54.8 KB

2

Hey @peterfwriter :waving_hand:

What you can do is create another database called “user-public-data”.
With all fields seted to public. But without any information.

When user choose to make his email public, for exemple, you can simple populate his “user-public-data” with his email. If he decide to make it private, you simple erase it from this database.

Make sense?

2 Likes
3

Shoot, that’s actually really smart!

Thanks a lot buddy, I’d definitely do that for sure! :folded_hands:

1 Like
4

I saw you’re struggling with how to let users toggle personal data (like email, mobile, landline, and address) between public and private modes efficiently. I faced a similar challenge in a past project, and I found a clean and scalable solution that avoids overcomplicated logic.

The key is to create a separate table that only stores the data the user wants to expose publicly. Then, visibility is based simply on whether a field is filled or not. Here’s how you can implement it:

Solution using user_public_data table

Step-by-step implementation:

1. Create a new table named user_public_data

  • Fields: email, mobile_number, landline, address

2. In the User table, create a relational field to user_public_data

  • Type: single relation (1:1)

3. On user creation workflow:

  • Create a new user_public_data record
  • Link it to the user being created

4. For toggling visibility:

  • If toggled to “public”, copy the value from User to user_public_data
  • If toggled to “private”, clear that value from user_public_data

5. On the frontend:

  • Use conditionals to only display fields that are not empty in user_public_data

Why this works great:

  • Drastically reduces complexity
  • Avoids dozens of conditionals and booleans
  • Keeps privacy logic clean and scalable
  • Easy to extend with permission levels later

Let me know if you want a visual model or quick demo on this setup.

5

Hey @digietalz.ag

Thanks for taking part in this solution. What you’ve just suggested is exactly the same mindset what @rpetribu has said and I also marked as “solution” because it works like a charm.

Still, thanks for taking your time committing your way of doing it, I really appreciate it.

Plus your detailed step-by-step explanation might come handy for others if someone researches the topic and doesn’t understand it from the first comment.

Keep up the good work and welcome on the forum!