What are forms?
Forms provide a way for users to enter and view custom fields in a format that closely resembles the order and arrangement of data in legacy systems or physical paper forms. Form rules provide a way to ensure data being presented and entered is both valid and appropriate for the role of user interacting with it.
Forms are configured by an administrator who then associates it with a ‘Complete Form’ task within a process template. When the task is executed, the end user opens the form to enter and save data, then returns to the task detail panel to complete the task and advance the workflow.
The ‘Complete Form’ task can also be configured to automatically save the form as a PDF and either associate it as a reference file or use it as an approval candidate – allowing users to mark-up the form in the Online Proofing tool, then (re)edit the form data in review cycle as needed until the form is approved. These options are part of the task configuration, and, if enabled, the PDF is automatically generated upon completion of the Complete Form task.
An auto name expression can be added to the ‘complete form’ task which will give unique names to the completed forms being saved as reference files or approval candidates.
The sample screenshot below is an example of a form with two tabs (‘Overview’ and ‘Packaging’). Fields in Red are required, other fields are optional.
See Form Administration for more information about managing forms.
Why use forms?
Here are a few basic scenarios where Forms might be helpful:
1. Basic use of Forms to collect and display data:
The first few steps of a workflow require data entry from different people to gather project or SKU information prior to the creation of artwork.
Form Task 1 = Marketing enters brand information
Form Task 2 = Quality views Marketing information (can edit a field or two) and additionally provides an ingredients list and nutritional information
Form Task 3 = Legal provides disclaimers and/or warnings
Form Task 4 = Project manager reviews all data entered, can edit some (or all) and provides additional instruction. Upon completion the rest of the workflow is executed (artwork upload, review, etc.)
2. Completed Form used as a Reference File:
The first few steps of a workflow require data entry from different people. The data collected needs to be a reference document / file downstream to assist in artwork creation or approval.
Form Task 1 = Marketing enters brand information
Form Task 2 = Quality views Marketing information (can edit a field or two) and additionally provides
Form Task 3 = Project manager reviews all data entered, can edit some (or all) and provides additional instruction. Upon completion of the task, a PDF of the Form is automatically created and inserted into the subprocess as a reference file for use in downstream tasks.
3. Form Approval:
The first few steps of the workflow require data entry from different people. The resulting data is displayed as a Form which can be marked-up and approved / rejected using online proofing. If rejected, the workflow loops back to the Form task(s) where user(s) can update the form data as needed for another review cycle. When creating new cycles, all optional and required attribute values on the form are retained on the next cycle.
Form Task 1 = Marketing enters brand information
Form Task 2 = Quality views Marketing information (can edit a field or two) and additionally provides an ingredients list and nutritional information
Form Task 3 = Project manager reviews all data entered, can edit some (or all) and provides additional instruction (This task is configured to automatically generate an approval candidate when this task is completed)
Proofing Task 4 = Reviewer-1 annotates and approves / rejects the form using online proofing.
* If Reviewer-1 rejects the Form while proofing, the workflow loops back to Task 3 above (it could be configured to loop back to Form Task 1 or 2). Data from cycle-1 is still available in the form for editing, and the project owner can open the annotated PDF in online proofing while updating the data.
Who can create and use forms?
BLUE administrators have access to create and manage forms. Once created, the administrator associates the form to ‘Complete Form’ task(s) within a process template.
Standard BLUE users interact with the form to enter and view metadata (custom fields) during the course of a workflow.
How do I create forms?
BLUE administrators can create and edit forms by selecting ‘Form Template Administration’ from the Advanced administration menu.
For more information, see Form Administration.
How do I configure a process template to use forms?
Forms are made accessible to end users by configuring a ‘Complete Form’ task within a process template.
Drag and drop a Complete Form task to your Process template.
If you need different people to collaborate in completing the data on a form you will need multiple Complete Form tasks. Each task could call a unique form to display only the fields that each user needs to see and / or enter.
Another approach could be to have all of the form tasks point to a single form that uses Form Rules to dynamically ‘format’ the form based on the user (or some other condition).
Configuration of the Complete Form task is similar to other user facing tasks. Properties specific to this type of task are explained below.
For the form task, on the Form (drop-down) – select a form to associate with this task.
The form task can have a form name expression defined to automatically name forms created from completing the task.
For more information, see Form Administration.
Data Input Form
Save form as…None. The form is just being used for data input. Users can still ‘save as PDF’ to their local machine at any time.
– No additional configuration parameters needed
Save form as Reference File.
Upon completion of this task, a PDF will be generated and saved as a reference file to the (sub)-process.
– File Type is required
– Status mapping for the Uploaded state is required
Save from as Approval Candidate.
Upon completion of this task, a PDF will be generated and saved as an Approval Candidate for downstream approval via the Approval or Review task.
– File Type is required
– Status mappings for the Approved, Rejected, Terminated, and Submitted states are required
– Approval Candidate ID is required
Configuration tips when saving the form as an approval candidate
Tip: The reject path of your Approval Decision should loop back to a Complete Form task.
Tip: If you open a form in cycle-2 (after a rejection) and the data entered in the previous cycle is not visible, go to Advanced Configuration >> Template Administration and ensure the Custom Fields in the Complete Form task are HOMED at the sub-process level and EXTENDED to the Complete Form task.
Standard BLUE behavior for Custom Fields homed at a task, is that the value of required Custom Fields (only) are copied from the previous cycle. Values for Optional Custom Fields are not copied forward to the next cycle.
Tip: Make sure the Approval Candidate ID is in sync with following Approval and Review tasks, but different than other Approval Candidate IDs that might be used elsewhere in the workflow (e.g. For actual artwork files)
For more information on related topics, visit these links…
For more information about template task node settings, see Task Node Settings.
For more information about completing forms tasks, see Form Tasks.
For more information about managing forms, see Form Administration.