Currently, every screen needs to be built individually. This is time consuming. As a general rule, when we create a request (as the orchestrator of the work package items), we must place all the data from all the tasks that we want to collect in the work package onto the request. However, you must create the fields on the parent entity first, then add them to the child entities (the tasks). This is true too for calls. If I built it once, I should not have to replicate that across all entities in the screen set.

For example, I created a procurement request form with 30 line items containing 5 fields each and several other main sections to collect information about the procurement. The screen itself has well over 300 fields. Each of the 30 lines (and each of the 5 fields per line) had to be hidden until it was needed, and if needed, special "required if" rules were also needed. This means there were show, hide, and required if rules against all 5 field for each of the 30 rows: 150 rules. Because the line items needed to be displayed on the request review, approval, and task screens, I had to repeat this process 3 more times. We cannot copy over between screens even if they are in the same screen set.

Since in MOST cases, all of the task data is needed on the request screen, and you have to create the field against the parent request in order to get the linking to propagate correctly, it makes sense that we should only need to create, place and apply rules to the fields one time and that anytime a field is added to the parent, it is dropped onto all child task screens. This way, all thats needed is to rearrange and polish the dependent screens rather than creating from scratch, including the rules.

When this is spread across, message templates, tasks, approvals, submission and review screens, the work is onerous and prone to errors. In a nut shell: the request Details screen should function as the screen set's "Master" screen and the dependent screens should automatically receive all the fields and rules, and layout options as they appear on the parent request screen. Once the dependent screens are created, the admin can further polish by removing fields they do not want to appear and updating or modifying rules. This implies that a "Lock" feature is needed to prevent ASM from overwriting the changes once the admin has finished the screen, or a versioning system for screens.

Lack of insight and visibility into the request from the task. The request is merely the orchestrator of all the work that goes into fulfilling that request. Some workflows can have hundreds of tasks. Currently, there is no visibility to the agent working a task as to what approvers or other agents have annotated on their respective tasks or notes that may have been added by the requestor's themselves. To see this information is a complex process that involves displaying the request and picking through the history of the request in amongst the numerous system messages. Along with automatically copying down fields to all related task entities, the request history, sans the system history events, should appear in a dedicated widget similar to the conversation history widget on all task screens. There is room at the bottom of the information panel for this thread.