Multiple editable reports on the same page
I have a list of tasks that I can bring over individually into a report with a "Add Task" button. My issue is that I need to be able to do that for 12 individual months and have each report by month t...
Forum Discussion
I think I understand what you mean. Yes I would like to pre-load a year's worth of tasks at the beginning of the project creation but I still need each months tasks to be editable. For example, January may have a task that is in progress until June but then in June it needs to be edited to complete.Is that where the automation comes in? Not sure if you can see my snippet below...
Are you planning on using the [Start] and [Finish] components of a standard-task table with Predecessors etc?
As an overall approach then; I would build a Template Project with associated Tasks against it. You will also need to a formula-checkbox to identify the Template Project so that other Users cannot accidentally delete it; and then make a custom role so that only the custom role can modify "Template" records (to protect your data integrity even from Administrators).
Build out the Task list, with the same task 12 times (one for each month in the year). Give each monthly same-task a Predecessor of the previous-month's Task so that they can "connect" to each other. You can of course have other Predecessors in addition.
Make sure your Tasks table has a Month-designation (I would recommend using a source-parent table called Months with the Key Field being a [Month] (text) value. Make sure your Months are a multiple-choice list and are shown in the "sort in this order" (not alphabetically). This can impact the way you see data when filtering on that value in another table. Also add a numeric field in that source-table of Months called [Month Order] and number the months in the correct order 1-12). You can then "lookup" this value in your Tasks table which will be important for sorting and grouping.
You will need to decide the finer-points of how you display these records in your Parent-Project record (I would not display 12 month's worth of tasks at the Project Level as that is a lot of data you would not need to display and will clutter up your interface).
Building automations to fully-complete a Task or customized formula-buttons which can allow a User to "complete" a Task easily from an embedded report will make your user journey much more friendly.
I also recommend having a variable in your application for the [CurrentYear] which you set every year. Then build a formula field in your Tasks table called [Current Year] which takes the Year([Start Date]). This will make it much smarter to use reports where [CurrentYear] is equal to the value in the field [Current Year] to make your yearly-rolling reports more automated and not hard-code the filters on your reports. This may be especially important with embedding reports on your Project form layout.
When you create a new Project, you will need to click a [Create Tasks for this Year] CopyMasterDetail button to create all the Tasks for the new Project. You may then need to use a Date field value in the Project by which to recognize which Tasks have been created that should not apply to the Project. i.e. if a Project starts now (July), there is no point having Tasks for January - June. You can trigger an automation to purge these; or build a custom button using the API_PurgeRecords to delete child records which meet a given criteria.
There are probably a handful of other things you will need to decide to get full user-adoption; but these will all help.
As an overall approach then; I would build a Template Project with associated Tasks against it. You will also need to a formula-checkbox to identify the Template Project so that other Users cannot accidentally delete it; and then make a custom role so that only the custom role can modify "Template" records (to protect your data integrity even from Administrators).
Build out the Task list, with the same task 12 times (one for each month in the year). Give each monthly same-task a Predecessor of the previous-month's Task so that they can "connect" to each other. You can of course have other Predecessors in addition.
Make sure your Tasks table has a Month-designation (I would recommend using a source-parent table called Months with the Key Field being a [Month] (text) value. Make sure your Months are a multiple-choice list and are shown in the "sort in this order" (not alphabetically). This can impact the way you see data when filtering on that value in another table. Also add a numeric field in that source-table of Months called [Month Order] and number the months in the correct order 1-12). You can then "lookup" this value in your Tasks table which will be important for sorting and grouping.
You will need to decide the finer-points of how you display these records in your Parent-Project record (I would not display 12 month's worth of tasks at the Project Level as that is a lot of data you would not need to display and will clutter up your interface).
Building automations to fully-complete a Task or customized formula-buttons which can allow a User to "complete" a Task easily from an embedded report will make your user journey much more friendly.
I also recommend having a variable in your application for the [CurrentYear] which you set every year. Then build a formula field in your Tasks table called [Current Year] which takes the Year([Start Date]). This will make it much smarter to use reports where [CurrentYear] is equal to the value in the field [Current Year] to make your yearly-rolling reports more automated and not hard-code the filters on your reports. This may be especially important with embedding reports on your Project form layout.
When you create a new Project, you will need to click a [Create Tasks for this Year] CopyMasterDetail button to create all the Tasks for the new Project. You may then need to use a Date field value in the Project by which to recognize which Tasks have been created that should not apply to the Project. i.e. if a Project starts now (July), there is no point having Tasks for January - June. You can trigger an automation to purge these; or build a custom button using the API_PurgeRecords to delete child records which meet a given criteria.
There are probably a handful of other things you will need to decide to get full user-adoption; but these will all help.