# Advice on how to construct a backend workflow to find number X

Good evening.

Looking for some guidance on how to approach constructing a backend workflow to determine how much someone should get paid from a given number.

As an example, assume that User A has £2500 and owes User B £1300.
Once deducted this leaves User A with £1200.
User C is also owed £1000 from User A.
However if User A transfers £1200 to User C then they will have been overpaid.
So I need to be able to workout what User A needs to give to User C in order for them to be paid accordingly i.e Number X

I initially thought of linking to recursive workflows together whereby it creates a data entry if X-Z is >0 (i.e User A paying user C does not result in a negative number i.e overpaying) but if it does, then feed the data to a second workflow with Z = Z+1 and run it again so it increments the value each iteration until it hits upon the number that is equal to 0 i.e the exact amount.

However with the numbers being in the thousands this obviously has potential to run 1000’s of workflows to find a number so is terribly inefficient and just not a “neat” solution in the first place.

I’m sure there’s an equation I can implement into it to work this out by my algebra sucks so wondering what alternative approaches I can consider if anyone can offer some guidance.

Thanks!

Hello!

I may be missing important context, but it seems like this should be able to be setup in a way that avoids the use of backend workflows all together.

My first thought is to have a data type called “Peer to Peer Bill” (or whatever you want to call it). This data type can have fields for “User Who Owes,” “User who is Owed,” “Amount Owed,” and “Paid?”

In addition, you’ll want a field on the user data type to keep track of their current balance.

From there, searching this “Peer to Peer Bill” data type should give you any answer you ever need to know about who pays who and how much.

For example, in the scenario above, user A would have the amount \$2500 in their current balance field, and there would be 2 peer to peer records in the data base:

• 1 record that says User A Owes User B \$1300
• 1 Record that says User A Owes User C \$1000

You could then show user A a list of their outstanding bills. Once they choose to pay User B, you could update their “current balance” field to reflect what they have left, and update the DB record for Peer to Peer bill to reflect that it has been paid.

Then, the remaining Peer to Peer Bill record would show that they only owe \$1000 to user C.

I recognize there may be some contextual reasons why this type of set up won’t work, but in theory, I can’t imagine a scenario in which a functionality like this would REQUIRE a backend workflow. I hope this is helpful!

1 Like

Apologies for delay in reply went on vacation.

Solved it in the end with a B/E workflow that calls one of two custom events that processes the data accordingly and then recursively calls the workflow again until all values are settled.

Thanks for coming back with the suggestion though - didn’t want it to appear I was ungrateful for the input!

This topic was automatically closed after 70 days. New replies are no longer allowed.