Summarizing within a table
I have an application with hierarchical tasks in one table. This tasks table is a child to a parent projects table. Each task will have various types of costs like labor, materials, etc. There would b...
Forum Discussion
Take a look at this @Paul Streit:
Parent Table with Summary Fields
When you relate two tables, you can add summary fields from the child table to the parent table giving you similar function of a summary report, but with dynamic filtering capability and you can export to spreadsheet.
------------------------------
Adam Keever
------------------------------
Parent Table with Summary Fields
When you relate two tables, you can add summary fields from the child table to the parent table giving you similar function of a summary report, but with dynamic filtering capability and you can export to spreadsheet.
------------------------------
Adam Keever
------------------------------
Adam,
The issue with using summary fields is that the hierarchy of tasks is variable in depth and breadth. For example, one project might have five levels vertically while another might have seven, and within any given level, one project might have three tasks while another has ten. If I tried to define summary fields at the project level for every combination of the hierarchy, there could be thousands of summary fields. The only level that is easy to do with summary fields is Level 1 because by definition there is only one element at that level (the apex).
This is like defining an app to capture the hierarchy of organization chart where the number of levels of the organization can vary (some companies might have more levels than others), and within a level, there could be different numbers of functions.
I looked at defining separate tables for each level with relationship lineage, where a Level 1 table is related to a Level 2 table which is related to a Level 3 table and so on, but that appears to be very complex, especially if other tables have to be linked to these tables for things like resource assignments (or in the org chart analogy, assigning employees to a specific function in the org chart).
Paul Streit
------------------------------
Paul Streit
------------------------------
The issue with using summary fields is that the hierarchy of tasks is variable in depth and breadth. For example, one project might have five levels vertically while another might have seven, and within any given level, one project might have three tasks while another has ten. If I tried to define summary fields at the project level for every combination of the hierarchy, there could be thousands of summary fields. The only level that is easy to do with summary fields is Level 1 because by definition there is only one element at that level (the apex).
This is like defining an app to capture the hierarchy of organization chart where the number of levels of the organization can vary (some companies might have more levels than others), and within a level, there could be different numbers of functions.
I looked at defining separate tables for each level with relationship lineage, where a Level 1 table is related to a Level 2 table which is related to a Level 3 table and so on, but that appears to be very complex, especially if other tables have to be linked to these tables for things like resource assignments (or in the org chart analogy, assigning employees to a specific function in the org chart).
Paul Streit
------------------------------
Paul Streit
------------------------------
- Do you have a business process map for what you are trying to do? Those can be helpful in understanding how the information must be structured and how it flows.
From my understanding of what you are stating, you would need these relationships one Project to many Tasks, one Task to many Sub Tasks, and an additional one Sub Task to many Sub-Sub Tasks. This set of relationships would not be negatively affected by the number of tasks. In fact this would allow you to summarize tasks so from your Project table you could see how many Tasks, Sub Tasks, and Sub-Sub Tasks are contained within that Project.
For example the Projects table with the number of tasks in each level:
Which can then be grid edited:
Most people stop at the sub task level. I am interested to understand your use case and why there are so many levels of tasks.
------------------------------
Adam Keever
------------------------------