Forum Academy Marketplace Showcase Pricing Features

Slow workflow process

Hi guys,

I’m looking for some help regarding one of my workflows.

So I have a list with codes (1,000 codes) which can be used to register to my app. When a user registers, the workflow that checks if that code is in that list + removing that code from the list so can’t be reused, seems to be really slow most of the time.

Is there a better way of doing it?
How can I speed this up?

Thanks a mill in advance!

How are you doing it now?

Is it a list of texts it’s searching through, or is it a data type Code and you have a ton of those in your database? The latter would be way faster for searching

Codes typename, and the field is Codes → List of text.

How else should I do it?

Reason I’ve done it this way is because I’ve had to upload it as an excel file.

Hi,

If my understanding is correct, you have a batch of some sort of “promotion” codes and users can use them to obtain some registration advantage or other. The codes are in limited stock, so when a given user leverages it, it must be “deactivated”.

This is how i would go about it:

1) Data structure

I’m going to suppose you want the functionality of code expiry to be extra reactive - no buggs or delays between when a user uses the code and the deactivation of the code.

:paperclip: create a data type called "Codes"
Field 1. Code | Type: Text
Field 2. Used | Type: Yes/No

2) workflows

:paperclip: When input value is changed:

:arrow_forward: If the code’s value doesn’t exist in your DB OR if it does but it’s status is YES, show error message “Code expired”.

:arrow_forward: If the code’s value exists in your DB AND it’s status is NO
Step 1. Set the value of the data type “Codes” ’ field 2. Used to YES
Step 2. Trigger an API workflow that deletes this code from your database.

:warning: Both these workflows should leverage custom events to make sure things run clean.

The reason i am breaking this down in two steps is that setting a value to yes is generally quick, and deleting an item is slower. To speed up the deletion process use a backend API to shift workload off the client side.

This way, we virtually eliminate the risk that between the time that the user sends the code and the actual deletion impact on the database, some other user inserts the code and the workflow doesn’t detect the change yet. By first setting status to “no”, we’re setting a faster appearing discriminant for our workflow to detect, all the while putting the workload of deleting codes to the back end.

Hope this helped.

Regards,

Cynthia

4 Likes

Hi Cynthia,

Thank you! I will update my backend accordingly to test this method :slight_smile:

By “Backend API” you mean a backend workflow deleting that code, right? So the same as I’ve been doing, just not “normal workflow” but a backend one.

Absolutely! Whenever you can, shove everything to the backend :slight_smile:

1 Like

Thank you!

And also, the “random item contains” - is the right one in the workflow, right?

Nope! « Contains » is not strict enough. Imagine a user types in « 80923 » and one of your codes is « 8092 ». You’re in à contains situation.

We’re in an event that should look like this:

1/OnClick event : when input value is updated (this is the input where your users type the code)
Only when: Do a search for :
Thing : Code datatype
Constraint : code = input value
Status = Not expired

:count=1 (this means that there is one code value that is the same as input value and it’s status is not expired)

Workflow: 1/ set status to expired 2/ run api (delete code backend action)

2/OnClick event : when input value is updated (this is the input where your users type the code)

Only when: Do a search for :
Thing : Code datatype
Constraint : code = input value
:count=0
OR Do a search for :
Thing : Code datatype
Constraint : code = input value
Status=expired
:count=1
(In other words, either the code doesn’t exist in your DB or it does but the status is expired and the workflow from previous delete API hasn’t completed yet )
Workflow: show error message

1 Like

Wow, okay! Thanks! That is so helpful! :slight_smile:

Only when: Do a search for :
Thing : Code datatype
Constraint : code = input value
Status = Not expired

You meant here : contains code= input value
Right?

Thanks a mill for all this help! Really, really valuable!

Nope, I meant constraint :wink: we’re constraining our search to this data type (filtering it)
The code MUST be equals to (« = « ) input value.
Not CONTAIN, that is not specific enough in my opinion!

1 Like

Really great, thank you!
And yeah, in order to do that, the “list of code” should be just simple text, not “list of text”. Makes sense.

Also, when let’s say, Users can stack codes (ie they purchase 1 code, 2 or 3) based on the number of codes they have, I change certain elements in my app.

Is that a good practice doing it this way:
List of code (within the User type) → when they have used a code, it’s added to this list.
So when they have used 2 codes → they will have 2 codes in their “List of Code” list.

And using the :count - here as well, for the different elements that I want to change, depending on the number of codes they have?
Ie if they have 2 codes: → :count=2
if they have 3 codes: → :count=3

If I understand correctly users 1/ purchase codes and 2/use codes.

So logically you should have a code data type referenced in your user data type.

However, instead of having two data types in each user datatype - one for purchased codes and one for used- I would have only one datatype « Codes » with a status field.

If you want to have a field in your user datatype that displays the number of used codes, you can achieve this with a database trigger event that listens to changes at the code’s status field level.

But you can also simply have an admin page for your app where you can see all your users and display this value via a « current user’s codes: filtered by: status=expired: count.
It all depends on how you want to visualise your data and the level of backend analytics you want to run in it.

1 Like

Yeah, so I have a “List of codes” added to the User datatype. Essentially, it’s a list of text.

The code, that the user bought (as we previously discussed, will be removed from the code list) + will be added to the user’s: List of Codes.
So essentially, they will have 1 code, 2 code or max 3 code in their “List of Codes” field.

And so, If I want a certain element to show, for example when the current user has 2 codes, I’d do:

“current user’s list of codes:count is 2”

Also, are you accepting projects by any chance? :slight_smile:

Absolutely. If you want to filter your user list for example and only show those that have two codes, you could apply such filter in the repeating group data source, or via a front end workflow custom event if you really want to optimise for speed.

1 Like

Of course! You can DM me if you want to share more on your needs, I would be happy to discuss.