Workflow

Locating the Workflow feature

Anyone in a Role with the Edit Workflow privilege can navigate to the Workflow by opening the PROGRAM DESIGN menu and clicking on the Workflow button.

How to create and edit the Workflow

We recommend picking one section of the Workflow to tackle first. When building out a program in PowerClerk, it is important to break down the program design work into manageable pieces. This could help a single Program Designer more easily scope out their work and maintain focus, or a team of Program Designers to work concurrently without encroaching on each other’s responsibilities.

Questions that need to be answered to build this single section of the Workflow:

• What status(es) are the focus of this piece of the Workflow?
• What kind of data will be stored about the project before it enters this step in the Workflow?
• What kind of data should be obtained and stored after for each completed step?
• What tasks need to be completed in this area of the Workflow?
• Who is in control of the project in this Status?
• Who needs to make changes, submit Forms, and attach documents in this Status?
• What handoffs have to be made?
• Do any email notifications (Communications) need to be sent out in this section of the Workflow?
• If so, in which statuses should they be sent, and to whom?
• Are there any Deadlines that need to be triggered by statuses in this section of the Workflow?

The next step in defining this section of the Program’s process is actually configuring the Workflow with the Workflow tool. Understanding the Workflow is key when managing a program in PowerClerk. The Workflow is the backbone of operations –the process defined in this tool will support many other aspects of the Program, including user behavior, Form configuration, and Actions like automatic Communications and Deadlines.

Although this feature is very visual and easy to use, any configuration work performed in the Workflow tool actually drives changes in the program’s code. This is one of the many ways PowerClerk is designed to be configured self-service, and without the need to be a computer programmer.

To create a new status within the Workflow scratchpad, click the Create New Status button in the upper left section of the Workflow screen. You will be asked to name your new status as shown below:

Your new status is now visible on the Workflow scratchpad:

For the purposes of this introductory guide, we will create a very simple section of the Workflow of what could eventually become a more complex Workflow. For now, we will only focus on three common statuses: Application Submitted, Application in Review, and Application Changes Needed.
 

Create two more statuses and name them “Application in Review” and “Application Changes Needed”:

Transitions

Status transitions are easily configured by dragging and dropping. To create a new Status transition, double click the area within a Status rectangle, a green dotted border will appear. Then, left-click and hold while dragging to any other Status. When second Status’s rectangle turns green, you can release your left mouse button, and a new Status Transition will appear. Note that orange Always Available statuses can be entered from any other status, therefore transition lines to them are prevented.

Statuses can be rearranged by clicking and dragging, and the view can be zoomed in and zoomed out using the buttons in the top-right of the screen or using the mouse scroll wheel. Combining these two actions can help make the Workflow more visually appealing.

 
To select and move a specific set of statuses (not necessarily close in proximity) hold the shift key and click the statuses one at a time.
 

 
To move a collective group of statuses (within the same proximity) hold the shift key and define the area for selection
 

 

To delete a Status or Status transition, expand the Status Name or transition in the Selected statuses table on the right, select the object, and click the Delete button. After you are done making changes, click the Save button to commit the updated Workflow to the program.

Think about the Status Transitions that are likely to be needed. The description above may have provided a sneak-peak at how this section of the Workflow should be configured. In our experience designing programs with numerous utilities, the following process steps are quite common:

• Once an application is submitted, that project should automatically move into the Application Submitted status
• Once an administrator starts the task of reviewing an application, the project should move to the Application in Review status
• If the application needs to be updated by the applicant, the project should be placed in an Application Changes Needed status
• Once the applicant has made their changes to the project, they should resubmit their changes to the administrator and their project should automatically move back to the Application Submitted status
• Once the Administrator starts their second review of this project, the project should be moved to the Application in Review status again

It is important to note that PowerClerk is designed to make the Status of each project visible to the pertinent stakeholders for that project (including administrators and applicants). Therefore,thoughtful naming of Statuses and thoughtful Status flow design will lead to happier applicants who intuitively understand what action is needed for a project, and when that action needs to be taken. Additionally, PowerClerk automatically saves a date-time stamp each time a project enters a Status, making it straightforward for the administrator to report on time spent in each Status or Workflow segment.
 

Changing a project’s status

A common task for an Administrator is to update a project’s status by selecting a project on the home screen, clicking Admin, and then selecting the Change Status function on the Admin screen. Note that a typical Administrator changing a project’s status can only select the statuses that follow the rules of the Workflow’s status transitions. However, if you have the Change Status Outside Workflow role privilege, you can change a project’s status to ANY status –whether that transition follows the normal Workflow rules or not.

See below a complex example of a Workflow that can build within PowerClerk to reflect the requirements of your utility program:

The above Workflow is composed of statuses and status transitions. Each status is represented by a rectangle. The text inside the rectangle is the status name, which can be changed at any time by selecting the status and clicking the Edit button (1).

The status’s color can represent one of two things (2): if the status is blue, the status is considered conditionally available, and any project that needs to enter that status must follow the available paths in the Workflow to get there. If the status is orange, that status is always available, which means any project can enter this green status from any other status, even if there is no status transition between the two.

The lines with arrows between statuses represent status transitions. These form the rules of the Workflow, which will be translated into PowerClerk’s code anytime the Workflow is saved. As can be seen in the screenshot above (3), if there is no transition between the Awaiting Documentation and Set Meter Request Pending, an application reviewer cannot skip over the Inspection Pending status – they must follow the allowable paths represented by status transitions. To create a new status, use the Create New Status button (4) and type a new status name. Note that each status must have a unique name.

Feature Reference

Workflow

Administrators have self-service control over the workflow for each program in PowerClerk, and each program can have a unique workflow. Using the graphical workflow editor (Figure 11), the administrator can create new statuses (Figure 12), delete existing statuses, and control the process flow between statuses (Figure 13). For simplicity, any status may also be defined as always available, which adds convenience as a few common terminal statuses (Cancelled, etc.) may become relevant at any time during the lifecycle of an application.

The administrator has the freedom to make changes to an existing program’s workflow at any time as requirements evolve. If a status is deleted by an administrator and any applications remain in the deleted status, they will still show as being in that status until they are moved to some other active status.

Thoughtful naming and configuration of the workflow can greatly aid in streamlining and organizing a program as Communications and Deadlines can be automatically triggered on a status change using the Actions tool. A representative workflow for an interconnection program has been mocked up in Figure 11 below. See “Communications”, “Deadlines”, and “Actions” sections for additional detail.

Video Guides

Would a video guide help to better explain Workflows? Contact us and let us know.
 

A full list of all Video Guides can also be found here.

FAQs

Q: I am running out of space designing my Workflows, what can I do?

A: statuses can be rearranged by clicking and dragging, and the view can be zoomed in and zoomed out using the buttons in the top-right of the screen. Combining these two actions can help make the Workflow more visually appealing. To delete a Status or status transition, simply select the object and click the Delete button(found near the bottom of the screen). After you are done making changes, click the Save button to commit the updated Workflow to the program.

Workflow Zoom

Q: Can I set the length of an incentive program to something other than 5 years?

A: Within PowerClerk please click on Program Design and choose menu option Incentive Design.
If you click Edit Design for an editable existing incentive or create a new Incentive Design, you will see that the Incentive Length field is editable and can have any value from 1 to 30 years.
In this same dialog you can also set other fields, such as Annual System Degradation. As the note on the page explains, that is a value indicating the percent by which the system production calculation should be reduced each year in calculating the estimated incentive amount. The default for this input is 0.0% -- no reduction. Note that it is a measure of the amount of reduction each year; so a value such as 0.5% would be typical.

Q: I am done setting up our program in the sandbox environment - how can I release our program to production?

A: Clean Power Research will take a snapshot of the program you want to move and then set that up on the production environment. We normally reserve 5 days just to give us some leeway in case there’s a problem and a hard deadline. You can keep using the sandbox environment during that time, but any changes you make there will not be reflected in the snapshot we took and hence any changes will need to be repeated in the production server.
Outside of that, the production server is just like the sandbox – nothing is set in stone, or needs to be final-final before going to the production server, you can make changes before and after you open it to the public.

Q: I added, enhanced, or improved an existing application Workflow, but have several unsubmitted applications. Is it possible to do a mass promotion on the Interconnection Request Application form?

A: We recommend not to utilize mass promotions for customer-facing forms, for the following reasons:

1. If an application isn’t yet submitted and you’ve added fields, those pop up towards the person filling out the form out of the blue, potentially on pages that were considered completed and now are not
2. Applications that have been submitted and got new required fields added now make an admin go “how did this get submitted without the field being filled out? It’s required after all!”
3. Applications that have been submitted and are being viewed by the user that filled it out now have fields, conceivably with values that an admin filled in later, that the user never submitted.

To help out utility customers that have a form that’s effectively faulty, we can target certain form versions and promote those. That is typically used for utility-internal forms (usually those that guide the admins through the process – if there’s a mistake on that, the form needs to change for all projects). If we used that, yes it would apply to the Unsubmitted applications.

Q: Is it possible for an Applicant to be in more than one status at a time?

A: A project can only be in one status at a time. An applicant (typically an installer/contractor) may have more than one project open in PowerClerk at the same time and these projects can be in different statuses.

Q: If a status in our Workflow leads to multiple other status options, can I manually select which status to move the Applicant to next?

A: Admins with access to the Admin View can manually select which status to move an applicant (see screenshot below).

Screenshot: Change status dialog

Formulas and Automations may also be utilized so this occurs automatically. For example: If Applicant A, should be placed in Status B because their system size is greater than 5 kW you would create a formula (system size is > 5 kW) which would then be combined with an Automation triggered by the submission of a form and an Action Rule that puts the project in Status B when the formula is true.

Have additional questions? Contact us to nominate your FAQ and help others find answers to your own questions concerning this feature.

Create A Support Ticket

Not finding your answer here?  Submit a question to our support team at the PowerClerk Ticket System and leverage the PowerClerk team’s expertise.