Skip to main content

Maturing your low-code factory: Supporting citizen developers with moderately complex use-cases

Timothy Harfield, 7 minute read

Pega’s Low-code Factory Approach to citizen development is ideally suited when an organization wants to support the proliferation of hundreds of simple applications that are built and owned by the same person: the maker. For the simplest use-cases, makers can build workflows entirely in Pega’s App Studio, which means that training requirements can be basic, coaching can be light, and time to value is low (in part due to App Studio’s no-code visual interface, and in part due to the use of templates to accelerate workflow development). Used in conjunction with Pega App Factory, this approach also supports delivery at scale because the enforcement of many best practices and technical guardrails can be automated in ways that reduce the need for ongoing intervention from IT.

As an organization’s citizen development program matures and makers become more skilled, the program may expand in scope and become open to delivering applications that are slightly more complex. For moderately complex departmental use-cases, it is possible to extend access to some makers beyond App Studio and into Dev Studio. With increased access to Pega Platform capabilities, comes greater power but also greater exposure to risk and a lower ability to automate compliance with best practices.

When a citizen developer program expands to allow some makers to take on more complex use-cases, several additional steps should be added to the build and deployment process:


To ensure success and to mitigate risk, makers should complete the right training prior to gaining access to more advanced features of Pega Platform. As part of the onboarding process, Practice Managers should assess maker skills against the complexity of the proposed build and recommend completion of appropriate training before provisioning an environment. (See below table).


Low-code Maker

Low-code App Builder

Low-code App Builder

Pega Low-code App Factory

Role(s) Makers Coaches and Advanced Makers Practice Managers
  • Making a request in Pega App Factory
  • Creating a new case type and stages in App Studio
  • Setting up users
  • Building a first step
  • Managing approvals<
  • Automating email
  • Routing work
  • Configuring SLAs
  • Making a publishing request through Pega App Factory
  • Defining a customer Microjourney
  • Designing a case life cycle
  • Completing work on time
  • Capturing and presenting data
  • Calculating values
  • Creating a data relationship
  • Viewing the data model
  • Routing assignments to users
  • Designing an approval process
  • Sending emails during case processing
  • Identifying duplicate cases
  • Adding optional actions to a workflow
  • Automating workflow decisions
  • Skipping a process of a stage
  • Creating a child case
  • Validating data against business logic
  • Gaining insight into business efficiency
  • Styling an application
  • Customizing portal content
  • Customizing a dashboard
  • Inviting users to an application
  • Setting up Pega App Factory
  • App Factory application life cycle<
  • App Factory go-live
  • App Factory retirement and graduation
  • DevOps
  • Reuse
  • Automation
  • Collaboration

In addition to technical low-code training made available via Pega Academy, many programs will want to supplement with bespoke training that includes additional business-specific content including governance, policies, additional technologies, and general ways of working.


A Pega guardrail compliance score of 85% or higher should be achieved for any Pega application in production, regardless of its complexity. Guardrail scores may be viewed via the Application Quality Dashboard in Dev Studio

For makers only using App Studio, the use of templates and pre-built reusable components will largely automate compliance with technical guardrails, but guardrail score checking is still an important step in the deployment process. A security review is also recommended, but not required.

When power users are given access to Dev Studio, however, additional measures beyond checking the guardrail score are required. The deployment process for these moderately complex applications should include functional and scenario testing, unit testing, as well as a security review.

To ensure upgradability, the App Studio Compliance tool in Dev Studio makes it easy to test the user interface. A list of additional checks is also available via the Pega Wiki.


Customized documentation is automatically generated by App Studio, but enterprise IT may have additional requirements that it wants to put in place for more complex apps. More robust documentation requirements are okay, but caution should be exercised by IT to strike a balance between the need for continuity, the complexity of the application, and the experience of the maker. If requirements are too onerous or complex relative to the criticality of maker-developed applications and are difficult to justify from the perspective of business users, then makers may be discouraged, give up, and/or look for alternative and unsanctioned paths to automation.


Regardless of application complexity, it is important from the perspective of long-term growth and sustainability that makers themselves continue to own the applications they create. However, there should always be a contingency plan in case the maker changes their job function or leaves the organization.

Data Access

Standard guidance for maker-built apps is that they are limited to internal users within a single department, that they do not require access to sensitive data (such as Personally Identifiable Information), and that they do not write back to systems of record. Where a maker has a business case to justify access to sensitive data, necessary approvals should be obtained and documented, including approvals for system owners. At every step, stakeholders should be comfortable that the use-case is a fit for maker-led development and be prepared to ‘graduate’ the application to IT ownership with significant increases in criticality.


It is important to keep in mind that just because a maker is advanced enough to use Dev Studio doesn’t mean that they should use Dev Studio. The default guidance to any maker should be to use App Studio where possible. If the maker requires capabilities that are not immediately available in App Studio, they should be added as reusable components. When complex requirements are proposed, a conversation should be had about the extent to which that complexity is actually necessary to drive real value. And before granting Dev Studio access, practice managers should carefully consider whether the need for additional complexity signals an increase in business criticality. If so, then graduation to co-production or IT ownership may be the best approach.


Related Resources

Don’t Forget

About the Author

Timothy Harfield, Ph.D., is Senior Director of Product Strategy and Marketing for Intelligent Automation Pega. 

Share this page Share via x Share via LinkedIn Copying...

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us