Designing Energy-Efficient Pega Workflows: A Step Toward Sustainable Automation

Sustainability is not only a hardware topic. Every database call, every background job and every screen refresh in a Pega application uses electricity somewhere. The good news is that the changes that make an application greener are almost always the same changes that make it faster and cheaper to run. This post is a practical checklist you can use in a design review. For the wider argument, see our companion article Sustainable Automation: Rethinking Pega Workflow Design for Energy Efficiency.

The checklist

Area	What to look for	How to check
Data pages	The same reference data loaded again and again. Wrong scope, or a refresh strategy that reloads on every access	Tracer and the clipboard: is the page reloaded on each screen?
Database access	Queries inside loops, reports with no filters, wide selects	Performance Analyzer (PAL) readings, database alert logs
Background work	Polling agents that wake up every few seconds and find nothing	Agent schedule, and log lines that show empty runs
Integrations	Several small calls that could be one, or synchronous calls that block a thread	Connector run time in the Tracer
Declarative rules	Declare expressions that recalculate more often than needed	Tracer, and the declarative network view
SLAs	Timers and escalations that fire rarely but are evaluated constantly	SLA rule goals and intervals

Five changes that usually pay off

Cache reference data. Put countries, products and branches in data pages with a sensible refresh time, and use node scope for data that is the same for every user.
Replace polling with queues. Move work from old agents to a Queue Processor or Job Scheduler, so the system only works when there is something to do.
Filter at the database. Put the conditions into the Report Definition, not into a loop that reads everything and throws most of it away.
Batch integrations. Send one request carrying twenty records instead of twenty requests carrying one.
Keep clipboard pages small. Do not load a full customer history when the screen shows three fields.

A worked example

A bank's nightly job reads every open account, calls a pricing service once per account, and then writes the result back one row at a time. On review the team finds three easy improvements:

The pricing table is loaded for each account. A node-level data page loads it once.
The pricing call is made per account. A batch call sends 100 accounts at a time.
The job is triggered by an agent that checks every minute. A Job Scheduler runs it once at 01:00.

The job now does far fewer database and network calls. Measure your own before-and-after numbers with PAL, because the size of the saving depends on your data.

How to make it a habit

Add a short "efficiency" section to your design review template.
Record PAL readings for the busiest screens before and after each release.
Set a rule that every new agent needs a written reason, because a queue or scheduler is usually the better choice.