Providing added flexibility and more power, combining what would have been multiple workflow rules into a SINGLE process. Salesforce Lightning Process Builder is a point and click graphical interface that provides a canvas for administrators to quickly and easily create workflow that used to require complex Apex coding. It has opened the door for administrators to design straightforward workflow that can create and/or update related records, including child records.
3. What is Salesforce Lightning Process
Builder?
A point and click graphical canvas interface
Builds Processes/Workflow with Clicks instead of
Code
Allows for consolidation of multiple workflows into
one Process
Provides for multiple potential outcomes with a
TRUE/FALSE tree structure
4. What does Salesforce Lightning Process
Builder give you?
Point and Click automation
Easier workflow management
More Power
Greater Flexibility
5. What actions can Process Builder do?
Create a record
Update any related record
Use a quick action to create a record, update a record, or log a
call
Launch a flow
Send an email
Post to Chatter
Submit for approval
8. Workflow Rules
Allows you to automate standard internal
procedures and processes
Is based on an object, has 1 set of criteria that
evaluate to TRUE (executing actions) or FALSE (not
executing actions) and actions that get executed
Can send email alerts, make field updates, create
Salesforce tasks and/or automate outbound
messaging
9. Approval Processes
Specify and automate the steps and sequence that is required
to approve a record
Allow for specific criteria to be met before a record can be
submitted for approval
Identify specific approver(s)
Can have multiple steps and different actions
10. Process Builder
• A GIU workflow tool that helps you easily automate your
business processes by providing a powerful and user-friendly
graphical representation of your process as you build it
• Extends the capabilities of classic workflow
• Still has some limitations
11. Visual Workflow
Automates business processes by building “Flows”, as
commonly abbreviated, and distributing them to the right
users or systems.
Guides users through screens that collect and display
information, create and update records, and execute logic
based on user input.
Built using Flow Designer, another drag-and-drop user
interface, used to create, manage and maintain the flows
12. Apex
Java-like, object-oriented program language that allows
developers to execute flow and transaction control
statements
Allow developers to add complex business logic to most
system events, including button clicks, related record updates,
and Visualforce pages.
Requires knowledge of how to write in Apex.
14. Process Builder Basic Steps
1. Define the Process Properties
2. Define the Object that triggers the Process
3. Define Criteria
4. Define Actions and Scheduled Actions
22. Where are pending Scheduled Actions?
You can see scheduled actions that are waiting to occur
in Setup under:
Build > Create > Workflows and Approvals > Flows
The scheduled actions are under “Paused and
Waiting Interviews”
24. Version Control
You can only have 1 active
version of a process
An active version of a
process cannot be edited
To edit the cloned version.
25. Troubleshooting Processes
User errors
Error emailed to Administrator
Apex Debug Logs
The record couldn’t be saved because it failed to trigger a flow.
A flow trigger failed to execute the flow with version ID 30100000000XXXX.
Contact your administrator for help.
26. Applications in Remedyforce
Auto submitting a Change Request for approval, based off of Change Type
or other Criteria.
Updating related Tasks, when an Incident is updated.
Sending Email using different templates based off of which Account the
User belongs to
Updating a Client’s phone number when it is updated on the Incident form.
Notifying a user that a Change Assessment hasn’t been completed when
they submit a Change Request for approval.
Appending to a work log field with information entered as Note Actions.
Updating a summary count field with the number of Configuration Items
linked to an Incident.
28. What did we learn about Process Builder?
Sleeker, Simpler User Interface
Added functionality
Can handle more complex processes than traditional
workflow
Still new and has limitations
Hi everyone. I’m Poppi Turlich and I’m a consultant on the Remedyforce Onboarding team at BMC. We develop and deliver best practices for Remedyforce implementations. I work with customers to configure their systems with a large focus on transferring knowledge. One of my goals is to ensure that every Remedyforce customer has the benefit of best practice experience and lessons learned. Last fall I wrote a white paper on Process Builder that is available on the BMC Remedyforce Community page. Today I am going to walk you through the highlights of that paper and show you both the basics and benefits of building workflow with Process Builder.
Let’s start with a little history on Process Builder and a brief overview of what Process Builder is, what it gives you, and what actions it can perform.
Lightning Process Builder was introduced by Salesforce in 2015, AND HAS HAD several enhancements added to it in recent releases. It is a point and click graphical interface that provides a canvas for administrators to quickly and easily create workflow that used to require complex Apex coding.
It has opened the door for administrators to design straightforward workflow that can create and/or update related records, including child records. These are things that COULD NOT previously be done with standard workflow rules.
Process builder also allows administrators to design an end to end process in ONE location, rather than using multiple workflow rules. With workflow rules, you are limited to a SINGLE if/then statement. Process builder essentially allows for MULTIPLE if/then statements to be created, executing the actions of the first matching criteria tree.
So, what does Process Builder give you? The most notable strength of Process builder is the “Canvas”, a point and click, flow chart user interface, allowing administers to drag, drop, and click their way through building complex workflows.
Process Builder can also help organize your workflow. With traditional workflow, you may have many workflow rules that support the same process. The only way to organize them is by some sort of naming convention, which can get messy. Process Builder allows you to see each of those workflows on one canvas, easily identifying which workflow actions happens when.
Process Builder is also built on the Visual Workflow Engine and it’s open source Aura framework. What does this mean? It means it’s powerful! Additionally, recent releases have also included better bulk record processing, allowing Process Builder to do more with less code.
The extended flexibility of Process Builder is evident with the potential for numerous criteria nodes in one canvas, but also in the additional actions that can be performed.
Process Builder IS the next generation of workflow, but it is also an easy to use, intuitive tool for administrators.
So let’s expand on why Process Builder is the next generation workflow…
Classic Workflow can only handle four actions: field updates, task creation, email alerts and outbound messages.
Process Builder extends these capabilities, allowing you to be able to BOTH create records and/or update RELATED records. Multiple child records can even be updated, which is something that was only previously available via Apex.
Process Builder also enables the ability for approvals to be automatically submitted based off some criteria, removing the requirement for human interaction.
Finally, Process Builder can launch FLOWS and SHARE INFORMATION with clients, by both sending email and posting to Chatter.
Now that we know a little bit about what Process Builder is, I would like to talk about how Process Builder relates to the OTHER available business automation options.
With so many choices for business automation, it may seem overwhelming trying to decide which one to use. Workflow and approvals can be confusing enough, but now there is also Visual Workflow and Process Builder… and we can’t forget Apex… Let’s take a moment to review each of them and discuss some best practices for use.
A workflow rule is a container for a set of workflow instructions. They automate processes within the tool, eliminating the need for someone to have to do them manually. Workflow rules execute as simple if/then statements. They are made up of 2 parts. The first part is the “if”, referred to as the “criteria”, which triggers the rule to fire when it is true. The second part is the “then”, referred to as the “actions”, which defines what should then take place. These are things like sending an email or updating a record.
If you have a single set of criteria and are just doing a field update on the current record or sending email via an email alert, simple workflow rules are probably still an easy way to handle those actions. However, keep in mind that each if/then statement, or each set of criteria, requires a new workflow.
Like workflow rules, approval processes have both criteria and actions.
Unlike workflow rules, that trigger automatically and when triggered are not visible to the user, approval processes are submitted for approval BY the user. Also, unlike workflow rules that only have one set of immediate actions, an approval process can specify different actions to take when a record is approved, rejected, recalled, or first submitted for approval.
A step can apply to all records included in the process or just records that meet additional predefined criteria.
Approval processes should be used when a user’s decision is required for actions to occur.
Process Builder is most closely aligned with classic workflow, offering a next generation GUI intereface, with some limitations. Process Builder expands the capability of workflow and should always be used if MULTIPLE if/then statements are required for a single process. It makes finding each of the workflow steps easier and eliminates the requirement to drill down into each workflow rule to see the associated actions, which can become quite cumbersome.
Process Builder also can be utilized to automate approval processes, when user interaction is not desired. Fields on records can be used as criteria to trigger different approval processes, all within one Process Builder process.
Though each release of Process Builder provides additional capability, there are still some things it cannot do. For example, Process Builder doesn’t support outbound messages. It also currently doesn’t have full Formula Support, which means all formulas supported in classic workflow aren’t available via Process Builder yet. These may be times when it makes the most sense to resort to classic workflow rules.
When thinking about Process Builder, remember that its focus is simplifying the behind the scenes “record based processing”. A process can only fire when a record is created or changed. It does not support user interaction, which is where Visual Workflow shines. With Process Builder, you define what will happen behind the scenes when users are manipulating records within the system. If user interfaces are required, Visual Workflow is where you should turn.
Visual Workflow, commonly abbreviated as Flow, provides the key function of building user interfaces. These interfaces, or screens, allow a user to progress through a series of steps or provide input. The key distinction with Visual Workflow is the “USER INPUT”. Visual Workflow is triggered by users, rather than by events.
Like Process Builder, Visual Workflow can also work with records, but it is not the record itself that triggers the flow. Process Builder should be your go-to tool for standard “if/then/else” record interaction, but Visual Workflow can be used as an option for record management when more complex logic is required, such as a criteria node based off of another criteria node. Though Visual Workflow is most commonly kicked off by a user (such as by a user clicking a link, a button, or accessing a tab), it can also be can be started from a Process Builder process or it can be called by Apex.
Apex should be considered when there is lots of information being handled or when there is complicated logic. There is no point and click GUI interface for Apex. Apex is a powerful programming language that should be utilized by an experienced developer when the other business automation tools do not meet the necessary requirement.
Now lets dig into how Process Builder works: how you create processes, activate them, edit them, and troubleshoot them.
There are 4 basic steps in creating a Process Builder Process. They are:
Defining the Process Properties
Defining the Object that triggers the Process
Defining the Criteria
Defining Actions and Scheduled Actions that Execute
To get to Process Builder, you go to Setup and then Create > Workflow and Approvals and then select Process Builder.
All of your Processes are listed in one place, showing a summary of when they were last edited and their current status (active or inactive). Clicking on the blue arrow next to the process name shows detailed versioning information.
Selecting the “New” button on your process page opens a window that allows you to give your process a name, meaningful description, and save it.
Creating a process starts with this simple step: naming the process and providing a description of what it does.
Once you name your process and save it, you will be taken to the process canvas. The canvas is the main workspace for Process Builder, offering a very simple, clean, point and click interface. To define any of the steps in a process, you simply click on the related shape.
The meat of EVERY process is the triggering object, the criteria tree and the actions (whether immediate or time-dependent) that you want have happen.
Of note for those of you who have played around with Process Builder previously, Spring ‘16 added the functionality to drag and drop criteria nodes, reordering them while editing processes. This allows you to change which criteria you want to have evaluated first, something that previously wasn’t available.
Once your canvas is open, you will start by defining the object that the process is based off of, know as the “triggering object”. This includes deciding whether you want the process to fire “when a record is created” or “when it is created and/or updated”.
The records that should be evaluated are determined by selecting the object where those records reside and specifying the changes that will cause the process to run. For example, you might select the Incident object and chose to start the process “when a record is created and/or updated”, which would trigger the process any time an Incident record was created or any time a change was made to an Incident record.
If your process is updating records, keep in mind that the object record that triggers the process is not necessarily the record that will have some action taken on it. Related and child records can also be updated.
The criteria, referred to as a “Criteria node” in process builder, are each evaluated to TRUE or FALSE. If the criteria evaluates to TRUE, the Action group for that node is executed. If it is evaluated to FALSE, the process moves on to the next criteria node to be evaluated. This evaluation continues until there are no more criteria nodes and the process stops. Each process will ONLY execute one Action group, the criteria node that evaluated to TRUE.
An example of a criteria might be when an Incident status changes. A status of “X” might be one criteria node and a status of “Y” might be another one. It is important to consider which criteria you want to have evaluated first and order your criteria nodes appropriately.
There is a limit of 50 criteria nodes, though such a large number of nodes is not recommended.
When criteria are met, the process executes the associated action group. When criteria aren't met, the process skips the action group and evaluates the criteria for the next action group. Remember that the process executes only one action group.
An action group can consist of a combination of immediate and scheduled actions. Immediate actions are executed at the time the evaluation criteria are met. Scheduled actions are executed at a later specified time.
As stated earlier, you are not limited to only performing actions on the triggering record. You can perform actions on child and related records. One example of this might be creating a task based off of a field being updated on an Incident record.
Each action group that utilizes scheduled actions can now have multiple schedules. For example, you can schedule some actions to be executed one day from now and other actions to be executed three days from now.
Prior to Winter ‘16, there was a limitation in Process Builder than only allowed you to have 1 scheduled action. With Winter 16, you can now have multiple schedules for things like notifications, further extending the power of Process Builder.
Keep in mind that the existing Salesforce limitation on scheduled actions still apply. Multiple scheduled actions are available when a process is defined to execute only when an object is created or when a field is updated to meet a specific criteria.
Winter 16 has also enhanced scheduled actions to ensure that the most current data available on the record is picked up when the scheduled action is executed.
Are you curious about what happens to pending scheduled actions?
Like classic workflow, you are able to see actions that have been scheduled and are waiting to occur. To see these actions, select Setup and then go to : Build > Create > Workflows and Approvals > Flows. The scheduled actions are listed under “Paused and Waiting Interviews”.
It is important to remember that in order for a Process to be triggered, it must first be Activated. Activated processes are read-only and cannot be edited. When you finish designing your process, don’t forget to click “Activate”.
Process Builder has extensive version control available to admins, allowing up to 50 versions of a process to exist. This allows developers to quickly switch back to a previous version if they have made an error in the editing process or if requirements change back to a previous requirement.
As previously stated, only one version of the process can be active at a time, and that version cannot be edited.
To make changes to an existing process, you have to first CLONE it. You can save the clone as a new process with its own version history or as a new version of the current process.
If you want the clone to run concurrently with the original process, use the clone to create a completely new process. You don't have to deactivate the first process in order to activate the clone.
If you want to make changes to the clone and use it to REPLACE the original process, save the clone as a new version of the original process. When you activate the new version, the previously active version is automatically deactivated.
One downside of Process Builder is the cryptic errors users receive when a process fails. Little information is provided to the user, leaving the user without the information they need to resolve the issue. When developing processes using Process Builder, I recommend additional time is added to testing the processes, with applicable user stories, to reduce the likelihood that users will see these errors.
The process administrator is notified, via email, when a Process Builder error is generated and displayed to the user, along with details on the error. If the email does not contain enough information for the administrator to troubleshoot the process, user debug logs can be used to allow for further troubleshooting. Processes created in the Process Builder appear as flows and workflow rules in the debug logs. The generated names have some resemblance to the process names, but they don’t map one-to-one.
In Winter ‘16, Salesforce has bulkified Process Builder to handle batch updates and data better, previously seen as a limitation of the tool. This should significantly reduce the number of errors that Process Builder was producing previously and allow more data intensive processes to now capitalize on ease of creation and maintenance in Process Builder.
There are many opportunities to utilize Process Builder to more efficiently manage workflows and to expand their capabilities within Remedyforce.
Let’s imagine you have a Change Process with different approval processes based on Change Type. You don’t want Requestors to have to go through the extra step of submitting the changes. Process Builder can manage all of the different approval processes in one place and fire the appropriate approval request when the record is saved.
Maybe you want to update all tasks related to an Incident, putting them in a “PENDING” status when the parent Incident is “PENDING”. Process Builder can do that too.
With a just few examples listed on this slide, keep in mind that there are numerous opportunities to utilize Process Builder within Remedyforce to automate and streamline your organization’s ITSM processes.
So we’ve reached the end of the road… but I want to leave you with a few final notes about Process Builder and what it delivers to Remedyforce.
Process Builder IS the next-generation workflow tool, providing added flexibility and more power, combining what would have been multiple workflow rules into a SINGLE process.
Process Builder will eventually replace existing workflow all together. With it’s intuitive, flow-chart driven user interface, business and IT come together nicely with point and click driven automation.
Today it is still a relatively new tool and there are still some limitations. When those limitations are an issue, working with classic workflow is still a viable alternative.
I hope this video has given you a better understanding of Process Builder and its capabilities. A key concept behind Remedyforce, AND a goal of our team, is improving time to value for our customers. Process Builder is a great tool to help get you there.
That concludes todays session.
BMC Remedyforce has an extremely active user community where you can get answers to additional questions on this topic and many others. We encourage you to take a look at bmc.com/communities.
There you can download the white paper on the this topic, as well as easily access many other whitepapers. There’s also a great deal of information on the Remedyforce product wiki page.
We will be doing more of these sessions each month, so please check back to learn more about how you can get value from your Remedyforce solution.
Thanks for your time and attention!