BPM Best Practice - Use at least 2-3 widgets (even if most is in C#)

I have written a large volume of BPMs
I have reviewed an even larger volume.
I have refactored a bunch (rewrite to make them run more efficient).
One common mistake I see over and over again, especially from Programmers is writing a BPM that is 100% C#, and only using one widget burying pop-up messages and exception messages inside the c#.

I would like to encourage this practice to change… I typically write BPMs that have at the very least, TWO if not 3-4 widgets, even if the majority of the work is done in a C# block.

  1. First a CONDITION: This condition widget determines IF this BPM needs run at all… Sometimes, i have found that the BPM is touched a bunch of times, when in reality, we only need to run the code “If the part changes”.
  2. The Action (or actions)… if done in C#, you can do all sorts of stuff… Even display messages, and throw error messages… DONT DO THIS… Don’t Throw Messages from within your C#… In my opinion, this just hides some of the activities. INSTEAD: If you want to put a message, build the message in a variable that you create called “StatusMessage” or “ErrorMessage” and use a widget to display this later.image

IF you have error messages, include the next widgets:

  1. MessageConditions Create a conditions to determine if there is something to display in your error message.
  2. Display Messages Display the message you built here…
    image image

ALSO in the messages, include the NAME of the BPM such as “Part.Update/Pre/MyBPMName” at the bottom of the message. This will help you later when some random popup message shows, and you don’t recognize it.

By following these guidelines, later debugging of code will be easier. You will KNOW just by looking at the flowchart that there is a possibility of it throwing an error or a message. But when you hide the messages inside C#, you have to open each one up to see if there is something that could throw an exception.
OK… i am off my soapbox.

OH… and dont be afraid to label your widgets! (OK… now I am done again)
Here is the final product:


Couldn’t agree more @timshuwy! Great advise!

1 Like

Hello Tim,
I try to follow what you mentionned, and yes, naming those widgets do help!

you mentioned about bilding a message:
“INSTEAD: If you want to put a message, build the message in a variable that you create called “StatusMessage” or “ErrorMessage” and use a widget to display this later”

Can you elaborate on this? are you saying to place the full message into a CallContextBpm string field?


You COULD put in into CallContextBpm.CharacterXX but instead, you can simply create your own variables (see bottom of screenshot) and then populate those variables if you need to display something. Then you dont have to make sure you clear out the call context (since call context travels all over the place from BPM to BPM.)