Ensuring compliance and upgradability by using best practices for application development

From PegaWiki
Best Practices for Application Development in Pega Platform / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Ensuring compliance and upgradability by using best practices for application development

Description Ensuring compliance and upgradability by using best practices for application development
Version as of 8.7
Application Pega Platform
Capability/Industry Area Low-Code App Development

Best Practices for Application Development in Pega Platform
New URL https://docs.pega.com/bundle/platform-88/page/platform/app-dev/best-practices-compliance-updatability.html
This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location.

This design pattern provides guidelines, in the form of a checklist, for application development in Pega Platform™. The intent of these guidelines is to help ensure correctness, performance, App Studio compliance, and upgradability. As stated earlier, these guidelines pertain to application development, but more specifically, these guidelines are relevant to developing applications in App Studio, or to ensuring that applications are App Studio-friendly.

Benefits of following these guidelines

Following these guidelines will ensure that the assets and rules created in Dev Studio are available in App Studio. Following these guidelines will also ensure that applications built in Dev studio will continue to function as expected with subsequent Pega Platform upgrades.

Audience for these guidelines

These guidelines should really be reviewed and internalized by any application developer developing applications in Pega Platform.


Case management

The following guidelines are applicable to the area of Case management:

  • Every instantiated work class has a case type rule defined on it.
  • Every case type is listed on the Cases & data tab of the application record, with the appropriate configuration to support its creation.
  • Every case type has stages (even if just create/new, open, resolved – CRUD style).
  • Every case type has a create stage and at least one resolution stage.
  • Define entry conditions for stages and gather related details before the stage is entered.
  • Standard prefixes new-, open-, pending-, and resolved- are used for all statuses.
  • Use the option to update status during case execution, as it helps to convey the case progress.
  • Complete Microjourney life cycle is clearly defined to the proper level of granularity. If it becomes large or complex, consider wrapping logical items into a subprocess or subcase and consider instantiating from the top-level life cycle.
  • While processing a list of embedded data objects, consider relying on subprocesses as that approach facilitates executing common logic against each list item.
  • All participants that have direct involvement in the case should be listed as parties.
  • Personas, channels, and system/data methodology should be included where required.
  • No actions should be hardcoded directly into the UI. Use standard case processing or optional case-wide and stage-wide actions in the case life cycle.
  • Avoid using tickets. Instead, use capabilities like the Wait shape.
  • Use standard routing capabilities.
  • Identify the list of case types, the instances of which could be associated at run time. A case and its association with other cases provide a more comprehensive understanding of how various cases are related.
  • Use standard views and design templates, and make sure all assignment forms are configurable using the configure form.
  • Ensure that proper validation is added to forms where required and add life cycle validation on the Data model tab of a case type. Form validations ensure that data integrity is maintained regardless of the channel through which the data is submitted.
  • Use attachment fields when the attachment or document is part of the data model and not just as an ad hoc/secondary/optional element to add using the attachment gadget.
  • Define explicit attachment categories and do not rely on the out-of-the-box file category. Explicit categorization will help you group related files and use the reference while sending out attachments by email.
  • For every task, consider defining relevant SLAs to ensure that users get the appropriate time to work on the task. SLAs can also be defined for a process, stage, or case.
  • Consider relying on urgency to convey the criticality and importance of a task. Higher values indicate higher importance. You can manage and change urgency via a local action or an SLA.
  • Ensure you identify and select only those fields that are required to be tracked and audited for changes (field-level audit).
  • When you need a case to be accessed simultaneously by multiple users, consider setting the locking strategy to allow multiple users.
  • Recommendation: Turn on the option to allow users to follow a case and be able to get notifications based on posts and events happening over the case of interest.
  • Recommendation: Consider relying on tag infrastructure to provide an easier means to associate multiple cases. Pega recommends providing a few default tags that users can rely on while working on a case.
  • Apart from standard pulse feed sources, consider configuring additional feed sources to provide users with a comprehensive overview of details related to a case.
  • Use the notification shape and notification framework for sending any notification, especially when targeting large groups.
  • Extend standard Pulse notifications to send to specific users related to the case. By default, Pega Platform sends notifications to followers, @mentions, and users who are part of the thread.
  • Mark important properties, actions, rules, etc., as relevant records for ease of use in authoring.


The following guidelines are applicable to the area of data:

  • All queries should use data pages and no top-level pages or direct report definition calls.
  • All data types used in an application should be listed in the application record.
  • Every data type should have a lookup data page with the key as a parameter. There should also be a standard list page that receives a standard/full list of the data objects.

User interface (UI)

The following guidelines are applicable to the area of UI:

  • For applications built with Theme Cosmos, use the prescribed overall experience, including the three-panel layout of a case. Focus instead on the core business logic and workflow. Modifying the prescribed overall experience will break upgrades to future version of the Theme Cosmos ruleset and will hamper migrations to upcoming platform architectures, such as Cosmos React.
  • Build Section rules based on OOTB design templates (1 column; 2 column; List Item; etc.) where possible.
  • Business logic and actions are in proper case management models and not embedded into custom UI.
  • Leverage OOTB formats in the skin.
  • Leverage Mixins to maximize consistency and reuse and to minimize code/rule maintenance.
  • For small styling adjustments, leverage OOTB CSS helper classes over new skin formats and custom CSS.
  • Avoid custom controls where possible.


The following guidelines are applicable to the area of DevOps:

  • Production rulesets are meant only for delegated rules, not for the creation of new rules. Avoid using production rulesets in development and staging environments.
  • Use the branch development feature while modifying existing applications with locked rulesets instead of simple branch creations in applications.


The following guideline is applicable to the area of security:

  • Adhere to the Security checklist application guide.