Pega's Bizarre Boolean Behavior

"Truth will always be truth, regardless of lack of understanding, disbelief or ignorance." – W. Clement Stone

While a clear philosophical statement, to Pega (and most programming languages), "Truth" is not "truth", and failure to correctly architect your application’s truth is setting it up for defects.

Pega, in a valiant attempt to streamline building your application, clouds truth behind an inconspicuous default: Text

Burdensome Booleans Blunders

You just snagged a super simple user story for the sprint! All you need to do is check if the customer is a U.S. citizen and display a message if they are.

After a quick chat with your LSA, lo and behold, there’s already a property flagging clients as U.S. citizens. There’s a long lunch in your future today!

A quick new section rule with the needed text, a simple visibility expression, and, BAM, off to your favorite pizza place (best slice in town)

Since your company is all about the continuous delivery life, your change finds itself in production just as you get handed a gorgeous slice of pineapple pizza (no judgements here). But, before taking your first bite, your phone buzzes… and keeps buzzing... oh no.

Every customer is seeing the message! How could such a simple piece of code break?

Bemoaning Basic Booleans

Understanding this oopsie means going back to basics.

TRUE, True, true.

To you and me, these all mean the same thing. We easily and quickly extrapolate the meanings to be identical, but, to a computer, these are three completely different things. Treating them the same in your application means you're going to have a bad time.

Developers get around this hazard by creating something special: A Boolean.

Booleans remove all the uncertainty for the computer, so: TRUE, True, true, yes, on, or any other variation imaginable are all abstracted into the simplest form: 1 as true and 0 as false.

Unfortunately, Pega creates an incentive to not follow this tried-and-true programming best practice.

Belabored Boolean Branding

For your super simple requirement, another developer had created the property: IsClientUScitizen. Unfortunately for you, the other developer created the property as text instead of a Boolean, setting up a chain of pain, resulting in the bug keeping you from your slice.

Herein lies the main problem: Pega defaults the property type to "Text", making it all too easy to just hit save and skip some extra clicks.

The busy developer who created the property as text opened a Pandora's box that may forever introduce production issues. Any future developer relying on this property has to be very sure they've accounted for all possible values it could contain. Sure, it's easy to simply cast the text as lower or upper case to create your comparison, but that doesn't solve the problem. What if someone decides to use "Yes", or accidently uses "Treu"? (Yes, I’ve seen this…)

I have lost count of the number of defects I've encountered over the years caused by every variation possible when using a text field as a Boolean.

Besting Boolean Bloopers

First, let's stop the bleeding.

When defining a new property and before saving it, a developer must change the type from the default of "Text" to the correct type, in this case: "TrueFalse"

This is the correct Pega property type for a "Boolean".

This Boolean blunder is even easier when defining properties/data types on a case, so take special care to define properties correctly when designing your cases.

Lastly, any text property being treated as a Boolean should be considered as tech-debt for future refactoring.

Backed Boolean Best-Practices

Returning to your, now cold, slice of pizza, you wonder what you could have done differently to prevent this unfortunate defect escaping into production...

Identifying a text property masquerading as a Boolean bestows three responsibilities onto you (one easy, one medium, and one hard):

Easy: Let your Lead System Architect and leadership know about the misclassified property so it can be documented for future remediation.

Medium: Ensure your comparison is case insensitive. Don't let a "True" not equal "true".

Hard: Research all scenarios where the property is set to ensure no unexpected cases, like the property being set to "Yes", or worse, a misspelling.

Belated Boolean Briefs (Final Thoughts)

I promise this was my last alliteration

Sure, Pega has made it a little too easy to lean on the text type, but, with the Swiss Army Knife that is Pega, the ultimate accountability rests with you, your team, and your code-review process.

I hope you enjoyed the read and will make catching misclassified Boolean properties a priority to save yourself and future maintainers of the application a headache or two.

Thank you for reading my article! 

What do you think? Comment below to share your insights/experiences on Booleans within your Pega applications.

About The Author

I am a hands-on certified Pega Business Architect and a true believer in citizen development; it is the future of business process management automation. I've survived and thrived multiple Pega application upgrades, including from version 6 to 7 and 7 to 8. In my 12+ years of experience with Pega technologies and solutions, I have come to find sharing my knowledge about Pega capabilities and best-practices to be one of the most rewarding aspects of my journey.