Forum Academy Marketplace Showcase Pricing Features

Privacy Rules - Do a Search

Have a question that relates to privacy rules and searching for things.

My users can send registration forms to customers through the app. The customer receives an email with a link that takes them to a registration form within the app.

I want to prevent duplicate form submissions from the same person, by checking email addresses. However, with strict privacy rules enabled, its not possible to check if an email address already exists in the database. I don’t want to disable privacy rules and expose all the email addresses in the system in the customers browser.

Is there another way to go about this without having to compromise privacy rules?

Great job!


You can do this using the Data API or Workflow API. I’ll explain using the Workflow API as using the Data API requires exposing it which I’d rather not do unless it’s essential.

Roughly speaking, what we’ll do is make an API call to a backend workflow that can bypass the privacy rules. This backend workflow will return a true/false statement via the API connector that tells us if an email exists in the database.

Create a backend workflow. Let’s call it ‘checkemails’. It takes one parameter - an email (of type text). Check ‘ignore privacy rules’ and check ‘expose this as a public API workflow’.

In this workflow, just add the ‘Return data from API’ action. The content-type should be Structured JSON. We’ll search the relevant data type (I’ve searched for users with a specific email, you might want to look for your Form submission data type).

So, if at least one user is found with this email, the API will return ‘yes’, and if none are found, it’ll return ‘no’.

Now, go to the API connector. Create a new API call group called ‘Bubble’. Use this group whenever you want to call your own app. Add the API token for your app (you can generate one in the API settings)

Then, let’s set up the actual API call. It’s dead simple. POST to[version]/api/1.1/wf/checkemails (checkemails is the ID of our backend workflow). [version] is a dynamic parameter so that we can dynamically specify the version when making the call using Isn’t live version:formatted as text. If Isn’t live version = yes, use version-test as the version parameter, and if = no, use version-live as the parameter. This way the call will work in both dev and live.

Add an email parameter which is of course the email you’re searching for.

Initialise, and voila:

If it finds a User with that email, it’ll return exists = true, otherwise it’ll return false. Hope it helps :slight_smile:

You can keep the email address hidden with privacy rules, but still allow the User to be found in searches…

That way, the email address is never exposed, but a search can be done (which happens on the server, and is secure), so you can determine whether a User exists or not with that email address, without ever exposing the email address to other Users.

This is great. Thank you for taking the time to detail how to go about this.

Are you referring to the “Find in searches” checkbox in privacy rules?

I couldn’t find much information about what data is or isn’t exposed with using this.


It does exactly what it says… (i.e. it allows the thing to be found in searches).

Okay sounds good. That would be much easier than having to setup workflow API. Drivers license numbers are also entered into the form and will be checked for duplicates, so just need to be sure that other data is not being exposed.

If you have that checked and nothing on the ‘view all fields’ checkbox checked then it will return a User (unique ID) but no associated data I believe. The downside is anyone (competitors for example) could keep track of how many users you have with a bit of technical skill.

1 Like

Not too worried about competitors. This is a tool for a small set of users and I’m not planning on profiting much from it. Just want to make sure data is secure/safe.

1 Like

Then my solution will be overkill :laughing:

Yeah, the only thing exposed inherently by allowing things to be found in searches is the unique ID…

Which, like most things, depending on your exact requirements/needs, may or may not be ok (but in most cases it’s fine)…

Permission to access specific fields can be done on a per field basis.

1 Like

Sounds great. I really appreciate the help and quick responses!

1 Like