Multi-Level Dossiers - Best Practice - Data Structuring, Cross site lookups, Parent-Child creation & inheritance
Greetings,
Apologies if my questions are ignorant, as I probably am! This post revolves around Multi-Level Dossiers & Cross Site Lookups… Best Practices… different approaches… how to structure (add/setup dossiers & inheritance in Solution Studio). Since it is a Multi-Level Dossier, I’ll try to consistently use Master – Parent – Child terminology. I feel like I've attempted most approaches, but likely in ways that violate Best Practices...or the way that data is inherited in each approach is being handled incorrectly.
(Yesterday, I created a Parent Item from the Master Display Form, and the data that was inherited was so inconsistent that I had no clue how to start to debug what the issue might even be. I have my Parent List columns set to inherit values from the Master. This is what led me to finally attempt to ask all of this...)
My main question here is rooted in: the best way to create new items, so that auto-populated data from the Master (Projects list), properly trickles down to Parent and Children. (Or the different options/approaches that are on the table, and best way to initially structure the solution’s levels.)
- I guess the ‘approach’ depends on where (Dossier Display form of Master; Button within an Edit form of a Parent/Child list; from the ListView of the Parent list; etc) the New Forms for Parent/Child lists are started.
- I really do not know what all options are available, nor the Best Practices for each.
- Options, off the top of my head:
- Option 1 – Create new Parents (Field Reports) from the Master (Projects list) Display Form. *Field Report columns would be set to Inherit from Projects. (All sub-items, of Field Reports, will then be created from within the Field Reports Edit / Display Form or selected single item in listview.
- Option 2 – New Parents (Field Reports) are created from the Parents listview, by selecting a single item, and basically cloning the previous report.
- Option 3 – Window Variables / Triggered Actions / Scheduled Actions / Javascript to set Lookup relationship / etc / etc
- Option 4 – ?
- Option 5 – ?
===========================================================================================
Additional Details & Pictures
===========================================================================================
STRUCTURING
When I initially setup this Solution, I created the Dossier's as such (in this Order, with this Structure:
Dossier 1 (Child – ChildChild)
- Subcontractors Main
- Subcontractors Daily
Dossier 2 (Parent – Children)
- Field Reports
- Actions Items
- Activity Log
- Delays
- …
- …
- Subcontractors Main
- Subcontractors Daily
Dossier 3 (Master – Parent)
- Projects
- Field Reports
- *(nothing under this, in this Dossier. Should all of the Children & ChildChild be added as sub items here as well?)
MASTER - Projects Lists
- New Items are created by using a Cross-Site lookup.
- 95% of this list is auto-populated from the lookup list.
- 6-8 fields are manually populated as well. 3 of these are People fields, which will control who is able to Create & Edit sub-lists, for a given Project.
- This List serves basically as the highest level of the dossier structure.
- A Manager will setup new Projects.
- *Field Personnel will then use all other sub-lists. This will ALL happen via a tab in Teams…keeping the End User in one spot is the biggest trick to this solution.
PARENT - Field Reports list
- This list serves as main Dossier for numerous sub-lists.
- Rework (Child)
- Delays (Child)
- Deliveries (Child)
- Action Items (Child)
- etc
- Each Project should have a Field Report item each day.
ADDITIONAL
It is desired so that:
- All Children (Delays, Rework, Deliveries) for a single Parent (Field Report), can be viewed in the Parent display form. [Basically, sub items created with a single day.]
- All Parents & Children for a single Master, which can be viewed via the Master's list display form.
===========================================================================================
OVERALL STRUCTURE
===========================================================================================
Projects lists (Master)
- Field Reports (Parent)
- Action Items (Child)
- Activity Log (Child)
- Additional Work Requests (Child)
- Delay Log (Child)
- Delivery Log (Child)
- Equipment Tracker (Child)
- Labor Log (Child)
- Issue Tracker (Child)
- Rework Log (Child)
- Tally Book (Child)
- Subcontractors Main (Child)
- Subcontractors Daily (Child-Child)
Option 1
Option 2
As always, I always appreciate yall's time, energy & help! Thanks!
-
Greetings and happy Monday,
To start, I wanted to clarify what I posted as an error/issue in my original post. The following can be ignored… “Yesterday, I created a Parent Item from the Master Display Form, and the data that was inherited was so inconsistent that… “
I now realize that in a True Dossier configuration, there are 2 steps to the inheritance… both: setting the Column Inheritance within ‘Things in the Background’ & setting the Initial & Calculated values on the Child’s New Form. (This makes sense.)
=== === === === === === === === === === === === === === === === === === === === === === === ===
‘Places’ a Child New Form can start (with Parent Context)
=== === === === === === === === === === === === === === === === === === === === === === === ===
To hopefully add context to my original question(s)…
Off the top of my head, these are the ‘Places’ where a Child New Form can be started, with the ability to bring in Parent Values.
- Parent Display Form, with Child ListView embedded
- The Child list configured with Lookup Inheritance
- The Child list not configured to parent, but use of Window Variables instead
- Parent ListView via Command Bar Action Button
- Window Variables
- Query/CAML Lists
- ?
- Within an Edit or Display Form
- Window Variables
- Query/CAML Lists
- ?
- An Action Button on a Site Page (new Skybow feature)
- Not sure how setting the ‘Parent Context’ would work in this situation, but I figure it is possible
=== === === === === === === === === === === ===
'Methods' of setting/passing Parent Values to Child
=== === === === === === === === === === === ===
Along with the ‘Places’ this can happen, these are ‘methods’ for setting Parent Values within the Child…
- True Dossier Lookup configuration (Inheritance + Initial & Calculated values)
- Window Variables
- Query / CAML Lists
- ?Javascript / REST?
- ?
I am not sure the different combinations of using the Places & Methods, and in a lot of ways, clarity of options & best practices, is a large part of what I hope to understand here.
=== === === === === === === === === === === ===
Quick Question 1
=== === === === === === === === === === === ===
Since I have become very comfortable with Window Variables…
What is the method of setting the Lookup to Parent column, using Window Variables? I haven't been able to figure this one out.
=== === === === === === === === === === === ===
Quick Question 2
=== === === === === === === === === === === ===
Are Triggered or Scheduled Actions a potential ‘method’ in all of this? If so, which situations would they fit?
As always, I appreciate your time & help!
-Taylor
0 -
Is it possible to set the Lookup Value for a sublist, via an Action Button, in the Parent Display form?
0 -
Hi Taylor
Yes, you can set lookup to parent item when opening subitem's NewForm via action link/button from main form.
One way would be to set the main item's ID into a window variable on form load of the main form: Just create a new Execute script action in the Pre-Form Load actions on the main form which contains: window.mainItemID = [[ID]];Then on the subitem's NewForm you set an Initial expression where you check if window.mainItemID is set, if Yes -> return this ID; if No -> return 0 (or null)
0
Please sign in to leave a comment.
Comments
3 comments