Understanding How to Use Constraints in Sign-up

Hello, I know this is probably a simple solution, so apologies for the newbie question.

I’m working on a sign-up flow where I need to see if an input field is contained in an existing DB of potentially eligible users. Each entry in this DB contains a last name, DOB, and the last four of the social. I need to see if the user signing-up exists in that DB by comparing the data they are providing during sign-up when they click the “Verify” button during sign-up.

I’m not sure how to construct an action in the workflow to achieve this result, where the intended outcome is to change a value in a User DB from “Eligible = No” to "Eligible = Yes._

Hey @max!

Here are some thoughts but I have to make some assumptions, so please correct me if I’m getting things wrong. Hopefully the logic still applies though.


  1. This is off a button click after the sign-up form is filled.
  2. The Eligible field is being set in the same “sign up” action.
  3. The data set you’re checking against is User, so you’re seeing if any other User records match the input info.
  4. If no users match, then Eligible = yes. I’m only assuming this because it sounds like you don’t want duplicates.

So when button is clicked > sign up user

Within the sign up action, the value of the Eligible field is going to do the check for you. For that field, the expression would be “Search for Users: count is 0”. The value of this expression is either yes or no. There are either 0 users that match your search or there is at least 1. 0 users makes the expression = “yes” and anything other than 0 makes it = “no”, which ultimately means you’re setting Eligible to = yes or no

Now the search itself has the following constraints:

DOB = DOB input’s value
Last Name = Last Name input’s value
Last 4 = Last 4 SSN input’s value

These all need to be present to return a user in the search.

Let me know if this gets you closer!

1 Like

@romanmg Thanks so much!

So my situation is a little different. I have one DB of users who are eligible to sign-up. Those users then will go through the sign-up flow to become site users. The logic then is going to be to see what the user enters into three input fields:

  1. Last Name
  2. DOB
  3. Last 4 of SSN

and then click a “Verify” button.

What then needs to happen is that a “Continue” button will become visible if a user can be found in the Eligible DB that has those three entries in the same record. Since theoretically there could be multiple eligible users with the same Last Name, for example, it is critical that the logic checks to make sure that the match is all within one record.

I feel like “intersect with” might help here to compare the three columns in case there are multiple results, but am not sure how to format the conditional expression.

Ok cool, thanks for the clarification.

Try this then. Create 2 events for when Verify is clicked, each with a separate condition.

Event 1: When clicked only when Search for Eligible Users :count is 1 > Show Continue Button

  • The search here has the 3 constraints: Last Name = lname input, DOB = dob input, Last 4 = SSN input
  • I assume the when Continue is clicked, you run the Sign Up action and set Eligible = yes

Event 2: When clicked only when Search for Eligible Users :count is 0 > Show alert message with error notice (or however you want to tell them they are not eligible)

  • The search has the same constraints
  • Perhaps you also add a sign up action here where Eligible = no

The “intersect” operation is for comparing two lists of things, so for example something like “Current User’s List of Purchased Products” compared to “Another User’s List of Purchased Products”. The result of this operation would be any Products found in both lists.

Thanks so much!

So the odd thing is I get with the Event 1, which should validate:

Here is a screenshot of the workflow and logic.

The dev site is behind a username/password, but this hasn’t been an error if I just default the user to .Eligible = Yes.

Do you have privacy roles set up for the Debt DB data type (or any other data type involved in the workflow)? Under Data > Privacy

There is! I’m not sure how it got there. I don’t remember setting this up nor defining the granular permissioning. Could a workflow or something else have created this?

Is there any harm in deleting it?