I am attempting to build the ability for a user to create a list of items (and quantity) that they would like to order.
These items are saved to the user as “Availability Inquiry” things.
I have business’s on my app. Each business has “stock item” things of what they have in inventory for sale.
I need to give the user a list of all business (if any) that show all stock items in the quantity that they want.
Then Have a second list that shows all business that have all of the items except for one.
Then a third list with all but two items and so on…
When I started building out this function, I was under the incorrect assumption that there was a backend workflow of “Create List of Things”. I am at a loss of how to build this out in a way that doesn’t burn through copious amounts of Workload units.
I currently have a data type of “Fulfillment Group” that I was attempting to automatically create/delete on the backend as the as “Availability Inquiry” things are created and deleted. Then do searches on the “Fulfillment Group” things to show relevant data to the user without layering searches on top of searches on the front end.
Looking for some ideas on how to set something like this up in a professional way.
Can you explain how you DB is actually structured?
I think your issue may be mostly related to DB design…
I’m not sure also to understand how you would use a create a list of things (if this was existing)… however the way to do that is to Schedule API Workflow on a list…
The goal is to show to user that are looking for parts, where they can get it. This is mostly the “Availability inquiry DB” that is the “requested parts” from user that you need to match with available Part stock. What is the purpose of the fulfillment group DB? From my point of view, this will cost you a lot of WU for something that I don’t think is really important.
But I understand you goal is to bring on top, the business that offer most of the items requested.
I think you have one missing DB that is to link all inquiry together (let’s say, an order DB).
I think that in availability inquiry, you could have one fields that will be linked to Part stock DB (a list). When user create an inquiry, you search for stock for this item (where quantity is >= requested quantity). Once all inquiry are created for an order, you can use a function to show which business have the most items requested using the Inquiry DB’s part stocks available’s group by “business” (with aggregate set to count). This will give you two other option’s business data (so you can show name) and also 'S count that will show the # of time a requested part is available for this business. No need to use backend WF at all and no Fulfillment Group DB (that will consume a lot of WU…)
I share your sentiment with regards to the fulfillment group DB! I generally don’t like it and am trying to eliminate it.
The idea behind it was to not have to keep doing a bunch of searches once the page loads and keeping some of the searching effort on the backend.
The basic requirement/s I have is for a user to have a page on the app that they can go to and add parts for a job over the course of days… these are the “Availability Inquiry’s”. I will show these in a list to the user at the top of the page and they can change quantity’s and delete them as they want.
From there I need a series of lists (tables really) that are distinct from one another to the user. The first list will show only if there are business that have all available parts. If there are multiple businesses that have all of the parts, they should be listed to the user in order of distance from user. Most of the time there are not going to be any business that have all of the parts though, so I need to provide lists after that initial list that break down “9 of 10”, 8 of 10, 7 of 10 ect. and order those lists by distance from the user. I also need to somehow indicate to the user what business have what parts on the list. (I have competitors that are somehow doing this. Me not having this is a common push back I get when selling)
Depending on how much WU this is burning, I may place limits on the user such as 5, 10 or 25 Availability Inquiry’s at one time depending on what plan they are on. (If I can figure out a way to have 50-100 as the limit that would be a dream!)
The Idea of the fulfillment group DB was to do some of the searching on the backend and have it saved until something changes so that there’s less searching going during page load/refresh.
Could you expand more on this?
This is kind of what I was thinking with the fulfillment group DB. I already have quote and order systems in place on the app. Part of this parts search functionality will be for the user to click a button to request a quote from one or more of the business showing availability. I should be able to run existing workflows that I already have for other quote/order request functionality on the app for this so I’m not as concerned about this aspect.
I like this idea! I don’t know if it completely solves my issue, but I hadn’t thought of this until now and It makes me want to play around with the idea!!
You could do the searching in DB directly for each Inquiry in backend wf and store the result in the inquiry. I think the best in this case would be to use DB Trigger WF on create and search values.
I think that what you was looking is to perform the search for all inquiry at the same time instead of one by one. The only reason why I could see a use for this option if to avoid doing the search for selected parts that user could choose to remove from the whole inquiry. At this moment a better option could be to create tempory item on the page using states and once use is ready to submit, you could use a backend WF with API Connector or better, Bulk data create with API.
For the order DB, the idea is just to have something to link all the inquiry together for a user at a specific time. this could also help to reprocess all inquiry search if for exemple, the user create a “cart” but doesn’t complete the TX and come back a few days later… you will need to check all inquiry items availability.
