Hello -
I’m wondering if anyone in the community has encountered a similar scenario to the below and how you solved for it and/or if anyone has thoughts on UI design concepts.
Objective
Building a popup that allows the user to create a record in a junction object. Need to provide the user a way to “search” from 3 levels up on each side to identify the objects that will go in to the junction as lookups.
Use Case Summary:
1) User must be able to “filter” by PO, then by PO Item and then pick a PO Item Ship Period
2) User must be able to “filter” by SO, then by SO Item and then pick a SO Item Ship Period
3) After identifying both PO Item Ship Period & SO Item Ship Period, user must input a numeric value
More details:
1) Purchase Order (PO) contains Purchase Order Items (POI) which contain Purchase Order Item Ship Periods (POISP). Same on the Sales Order Side (SO->SOI->SOISP).
2) Junction Object between POISP and SOISP called Allocation. User can allocate some or all of the quantity of POISP to SOISP.
3) In most cases, the users will create allocation record either coming from PO screen or SO screen so one side is “known” but the other needs to be searched for. Ideally, the design would work even if neither side was known initially.
4) Identifying a side of the junction requires finding the target SO/PO, the Item inside (POI/SOI) and then the ship period inside that (POISP/SOISP). Unfortunately, due to data complexities, identifying which item and which item ship period is not as simple as displaying a “name” field so table filters won’t work well due to length of data required to display.
5) Since only 3 data points are needed to create junction (search fields not included), the popup needs to be a single page (no wizard) so that users can change “search” criteria easily (minimize clicks).
6) I’d like to have the junction object only have two lookups - one for POISP and one for SOISP. There is no need to have lookups to PO, POI, SO & SOI.
Designs Considered So Far
1) Add PO/POI & SO/SOI to junction object and use lookup filters, etc. This will technically work but the only reason for adding these 4 fields would be to drive the UI and having them adds validations (everything must be from the same PO & PO Item), etc. that would otherwise be unnecessary.
2) Create a “AllocationUIHelper” in SFDC that never contains any records but it used strictly for a field editor to aid in searching. The downside here is that I have an object that would otherwise not be needed and also I’d be using multiple field editors so UI spacing/positioning wouldn’t be ideal
3) Write a custom component that has input fields necessary to capture the information required. The downside here is custom code and also lose the ease of stock features such as search filters, etc. This can all be accomplished programmatically but more difficult to maintain/support.
4) Not possible today (without come creative coding) but if there was a way to define a custom search popup to replace the stock popup that would allow me to keep just the 3 fields I need and build a intelligent popup using a field editor (would still need AllocationUIHelper object probably) and a table.
Does anyone have ideas or possibly implemented a solution that allows the user to specify “search” criteria that will drive the user down a dependent path of data (PO then PO Item then PO Item Ship Period) without having fields directly in the object to search on?
Any thoughts/assistance is greatly appreciated!
Junction Object UI Design Ideas for complex assocation
+13
+20Have you considered using queue’s to navigate your structure like Windows File Explorer. You can conditionally render one for each side of the junction. Levels 1-2 would set and render levels 2-3, while level 3 would be selecting the target record.
+17- Nintex Employee
My first instinct here is that your data model is complex enough that a wizard is merited. Though you say your users want to minimize clicks, I’m thinking they are going to have lots of clicks whether as a series of popups, or a set of steps in a wizard. The wizard process seems more intuitive. This is just my opinion.
In either case, you are going to need a table on your first level relation (PO Item Ship Period) that also contains the second and third level items as fields, and hopefully filters. (I hope that some field in PO and POISP are searchable / filterable…) When the appropriate row is found in your list, a row action can be created to assign that value to the appropriate field in the new row of the junction object.
If its a wizard, each side of the junction can be a step in the wizard, and you can conditionally render the table selection UI (or entire step) if one side is known.
If its a single page, I think you could use a button to launch a popup that had the custom table described above. Again, conditionally render the popup button if one side is known.
+13Hey Pat - Very interesting idea. I considered queues but was envisioning drag-n-drop between queues which wouldn’t work for the junction object. However, your post made me realize that I could have two queues and when the user selects the 3rd level, it uses action framework to update the corresponding field on the junction object. I’m going to explore this, it might work really well - could even add drag-n-drop on to a “target” area that represents the junction object in the middle. Thanks!
+13Thanks for the thoughts Rob.
I definitely agree that a wizard is the most intuitive approach, unfortunately the users won’t buy in to it 😦 There are two reasons here which I understand their perspective on: 1) If they need to change one of the search criteria, they need to go back to that page and then go back to final page to finish. Because the data is so similar from PO to PO they’ll often pick the wrong one. 2) They want it to behave like a pure data entry screen and in the end, they really are only giving 3 pieces of data (POISP, SOISP & Quantity) - all the other fields are there to support “searching.”
Question - If I went the wizard route, I would need to have a custom object that contains the additional 4 fields to support the searching even though the junction object itself really doesn’t need to hold those 4 fields, correct?
Regarding the table approach, I’ve thought of something similar to what you describe. Basically a table for PO/POI/POISP & another table for SO/SOI/SOISP with row actions on each to set the appropriate value on the junction object. This keeps everything on a single screen. The challenge here is that, since the data is so similar from PO to PO, the stock filters just don’t allow enough real-estate (once you pick the value, you only see a small portion) to display enough data to make this intuitive enough for the user. I know there has been talk about adding the feature to allow searching at a column level instead of globally in a table. This would be a great use case for that feature. The user could go to each column and search just like if they were separate fields in a field editor and this would avoid having to add unnecessary fields to the junction objects just to support searching.
On our current PO and SO pages, we have a table (POItems) that has a drawer which has a table (POISP) similar to what you describe. If the user clicks the row action on the POISP, we have the answer to the left side of the junction and would only need to ask for SO, SOI, SOISP.
Here is a snip of what I’m thinking with a single field editor. There would be conditional rendering on the fields to hide if we already know the answer as well as show/hide as the user fills out the fields (e.g. SO Item wouldn’t show until SO has a value, etc.). The downside to this is that I have to add 4 fields (PO, POI, SO, SOI) to my junction object just to support the UI searching:
+13Thought through this some more and realized I’m going to run in to the same filtering problem with queues that I would with tables. Because of the data complexity, I need to be able to show enough text to make the filter value discernible to the user after input. To do this, I really need a longer text field area which is only possible with a field editor or custom component. I could put fields in a field editor above the queue to support this. For example, PO, POI then queue of ship periods and the same for the SO side. The downside to this is that I have to add those fields to the junction object which I’m trying to avoid. The AllocationUIHelper object would accomplish this as well and avoid unnecessary fields on the junction.
I think I might just have to relent and add the fields to the junction or create the AllocationUIHelper custom object for UI support 😦
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.