Have 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.

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. 

Hey 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!

Thanks 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:

Thought 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