- Gather all documents related to your process (flowcharts, google docs, checklists, excel files, etc.) to have as a reference while building.
- Consider whether any of your process documents should be replaced by Catalytic. Examples: 1. Catalytic data table rendering a separate excel file obsolete. 2. Checklists replaced by tasks within Catalytic.
- Determine the best starting and ending point for your process template. Example: An employee promotion process may include a section for approval to increase the employee's salary. However, salaries can be increased at other times as well. In this case, creating an employee promotion template which then triggers a separate template for the salary increase approval would allow for usage in both circumstances.
- Name: Create a short but meaningful title with key words which will be easy for anyone to find. If creating multiple templates for a single process, consider the following naming structure: 1. Consistent prefix (allows for easy search and clear understanding that these templates work together as a group), 2. Numbering (helps to ensure you are aware of all templates and their order), 3. Specific suffix (to clarify what this piece of the process contains). Example: Month-end Reporting 1/2 - Starter, Month-end Reporting 2/2 - Publish Reports
- Description: Consider including the types of triggers, who should be starting this process and date created/updated.
- Permissions: Set default field permissions now if most fields are confidential. Note: This can be changed anytime throughout the build process.
- Fields: Template level fields can be very helpful to reduce the amount of hard coding throughout your template. This will help with consistency and better efficiency for future updates. Example: Setting up "roles" is a great use for template level fields. HR manager email field with the default value firstname.lastname@example.org. This field can be used to assign tasks, sending emails, adding as a contact in email bodies, etc.
- Always think through whether there is an option to create an automated trigger. Creating a weekly scheduled trigger will always be more effective than a human remembering to start a process each week. This goes back to let people do what people do best, and let Pushbot do what Pushbot does best. Triggering from another process or an action within other systems is also a great way to ensure your process starts on-time every time.
- For many automated triggers, the Run Owner will default to the Process Owner. If this is not ideal for your process, use the Pushbot: Update Owner action to change the Run Owner once the process run begins.
- Rename the process run: In the most cases, it will be advantageous to rename the run using the Pushbot: Rename this Process action early on in the process, once key field values are known. Example: Employee Onboarding process - add the employee's name and start date. This will allow for better visibility when reviewing open process runs and ease of searching. Another great use of this action is to rename the process run when it is in a waiting state, meaning no action will be taken for a significant period of time.
- Task naming: For Assign Task to a Person tasks, be sure to consider the person completing the task. It may make sense from the builder perspective, but not provide enough context for the task assignee. Example: Input Information vs. Input Details for your I9 & W4. For large templates, it may make sense to create sections or add numbering to your task names. Examples: System Access: Add to Google, System Access: Add to Salesforce, etc. or 3a - Add to Google, 3b - Add to Salesforce, etc.
- Dependencies: Always keep to a minimum to prevent bottlenecks in your process. It is easy to add a dependency as that is how the process typically runs. However, this is the time to consider whether efficiencies can be gained.
- Conditions: To provide flexibility for future updates, use the most general term possible for your conditions. Example: "willow" : is in : fields["tree"] is more flexible than fields["tree"] : is equal to : "Weeping willow tree". This same practice can be used for field conditions.
- Feedback task: Consider adding a task/email towards the end of the process to obtain feedback from those involved in the process. Once you start using a new template, there will inevitably be edits to fine-tune the process, and this will help to gain the feedback and drive changes sooner.
- Reviewing values: It can be helpful to repeat a field in a webform/task after the value has been entered. The value will appear in the second place it is referenced, and it can be reviewed/edited at that point. Example: A hiring manager enters a salary request for a new position. It is sent to the Head of HR for review. HR can review and edit directly in the field before finalizing.
- Using default values: Setting default values for fields can be used as mentioned above in the Template Creation section. Another example: Add the email body text as the default for a field within an Assign Task to a Person task. This will allow the user to review/edit the email body before the email is sent in a future task.