In Pega 7.2 and Pega Express, enhancements to the Direct Capture of Objectives (DCO) simplify creating and reusing specifications and documenting applications, application profiles, and specifications.

Create specifications in Case Designer
​
In both Pega 7.2 and Pega Express, you can now create and associate specifications with steps and user forms while you are configuring a case in Case Designer. Keeping this information current helps to manage the expectations of stakeholders, minimizes unnecessary work as goals change, and helps to reduce scope and feature creep.

Document your application
​
In Pega 7.2, the user interface for generating application documents, application profile documents, and specification documents has been redesigned. The new Document Application tool replaces the Application Document wizard and provides a streamlined landing page for all document types, including custom templates. After selecting a document type, you can configure the document by using just one or two screens, depending on whether screen captures are required.

​Successful software implementations use methodologies and tools that enable an organization to build and implement change quickly, manage and monitor the process and progress from start to finish, and demonstrate measurable success.  The methodology and tools are collaborative and flexible in design and functionality to maximize productivity and achieve the targeted return on investment, on time, to recognize the business value sooner. Pegasystems' SmartBPM and Pega Scrum methodologies align the implementation  with your corporate goals and practices and support consensus on the definition of project phases, deliverables, cost control and governance. Resources and stakeholders always have a clear view of what is being implemented and their role in its development.

Highlights of the Pega 7 Platform

The new Pega 7 Platform offers features that can engage your application users on various levels. Experience the following advantages when you upgrade to the latest version:

• Easily adaptable applications to engage more users through more channels and harness the power of big data analytics.
• Easier application enhancements and maintenance.
• Improved business agility through enhanced system development speed and accuracy in the three most critical and generally time-consuming areas: getting the requirements right, getting the user experience right, and getting the data right.
• For IT organizations, reduced application operating costs with tools to proactively manage their applications and robust infrastructure to eliminate unplanned downtime.
• A high-performance platform that is better suited to multitenant environments, helping to reduce costs.

The following table highlights new and enhanced features in the latest version.

​World of possibilities

Many existing Pega 7 Platform applications were created when smart mobile devices and social computing did not yet exist or were in their infancy. Today, these technologies and the data that they produce create opportunities to enhance the value of these Pega 7 Platform applications.
The Pega 7 Platform offers its customers a broad range of new and improved features that enhance the capabilities of deployed systems, reduce the ongoing cost of operations, and reduce the time to deploy new projects.

Engage more users through more channels
The rapid proliferation of mobile devices and social channels creates opportunities for companies to better serve customers and empower employees wherever they go. More and more, consumers take mobile access as a given. And with social networking technology, they are empowered to complain publicly if they do not get what they want. This empowered customer is changing the marketing and service landscape for all consumer-facing organizations. Even the world’s top brands have been challenged to keep up with the fast pace of change. More than one billion customers engage with the Global 500 on social media, but Maritz Research shows that 70 percent of customer queries and complaints through this channel go unanswered.
Serving users on mobile devices compounds this challenge. Current industry practice is to build seven versions on a minimum of five platforms, such as for example, a Web App, Mobile Web App, iPad App, iPhone App, Android App, BlackBerry App, and Windows Phone App. These channel-specific applications limit reuse and create a fragmented experience for customers and users. They also make it hard for your organization to interact with customers to understand their needs and solve their problems.
Recognizing these challenges, the Pega 7 Platform introduced Omni-Channel UX to open applications to mobile and social channels. The Omni-Channel UX “design-once, access anywhere” user experience delivers consistent, attractive, and intuitive user experiences across all types of devices.

In the Pega 7 Platform, you create your UI design once, deploy on any device, in any locale, in any browser. No coding is required: the Pega 7 Platform automatically generates the details—the semantics specific to browser and device environments, such as mouse-oriented or touch-oriented features that are automatically selected depending on the device. This means that you and your customers can get projects done faster, at lower cost, and with greater agility to respond to changes in the future, including the addition of new interfaces and channels.
The Pega 7 Platform supports three types of mobile experiences—Mobile Web, Pega Mobile Client, and Pega Mobile Mashup within the Pega 7 Platform.

• Mobile Web provides users with an optimized web browser experience regardless of device and screen size. It makes it easy to mobile-enable existing applications without having to develop in separate tools.
• Pega Mobile Client allows organizations to create a branded Pega 7 Platform-based mobile application that is distributed through an app store. This approach provides offline operations for use in places without network connectivity as well as access to mobile device-specific features, such as the camera and signature capture.
• Pega Mobile Mashup provides a way for organizations to take components of a Pega 7 Platform application and embed them in an existing, native mobile application.

The Pega 7 Platform also has the tools you need to manage access to these applications. The Pega 7 Platform supports Smart App Banners as a way to notify mobile web users of the availability of a native version of the application without requiring them to visit an app store. Organizations can also distribute native applications through the Pega 7 Platform Mobile Device Management capabilities. These tools can be used to push applications and application updates to Pega Mobile Client and other mobile apps.

Enable social collaboration in the workplace​​
Half of all information workers today use social collaboration tools to share documents. They also use these tools to communicate with customers and find experts or information inside their companies. It makes sense, because they use these incredibly intuitive tools in their personal lives. It is natural then that your employees use these tools as well to help get their work done in the office.
The problem is that this type of collaboration goes on without the security, control, or auditing of managed business processes. You cannot simply stop people from using social tools. But, social tools—disconnected from the work being managed—cannot be trusted to get the job done. And, social collaboration with customers cannot be audited later to examine what happened if something goes wrong.
Pega Pulse is a social collaboration tool that integrates the online conversations of employees, partners, and customers into the work being done. Fully integrated in the Pega 7 Platform environment, Pega Pulse gives users the tools to chat easily with colleagues. In addition, users can advance a process or resolve a case directly from their conversation feeds, and even incorporate conversations from external social media networks. And, because they are doing this in the context of a Pega 7 Platform application, all their discussions become part of the case history so that everything is in one place for later review or audit.
​​

Provide secure, interactive online supportA key part of servicing customer requests over the web is guiding customers to the products that they need or assisting them with submitting information online. Web page co-browsing is an excellent way to provide this level of service, but the proliferation of devices, form-factors, and browsers appear to be daunting hurdles to overcome. Pega Co-Browse provides a way to offer live, interactive, and secure support on your website without stumbling on any of these hurdles. Pega Co-Browse supports both desktop and mobile devices—regardless of form-factor—without the customer needing to download any software. With Pega Co-Browse, your customer service representatives can provide the guided assistance your customers need in a highly secure way because Pega Co-Browse prevents even your employees from seeing your customers’ confidential information.
Improve the service experience with customer process manager enhancementsIn Customer Process Manager (CPM) 6.3, the Pega 7 Platform introduced end-user experience improvements to help CSRs save steps and operate more efficiently, reducing average handling time and training costs. In addition, CPM 6.3 introduced CPM Composites, an improved screen layout for CSRs that provides pertinent customer information. The Interaction Display Option gives two options for displaying the CSR’s interaction panel. It can be displayed as an overlay or as a modal window. This means that multiple actions can be completed at once. CPM 6.3 also added an Express History feature that can create a tracking note to log an auditable interaction with the customer, such as sharing payment amount due or account balance information.
The new Unified CPM Dashboard has a standardized dashboard across CSR and supervisor portals. The dashboard displays distinct graphs based on the user type. The dashboard includes a work-centric view that has improved sorting and filtering of as well as search for work items.
Enhance applications with big data analytics that business people can useToday’s big data resources and advanced analytics create tremendous opportunity to more meaningfully engage customers with personalized service and offers that anticipate their needs. However, the fast growth of data and a shortage of data scientists to make sense of big data make it difficult and expensive to harness its power. Simply put, companies struggle because they cannot access the data, they cannot make sense of it, and they cannot use it when they need it most—at the point of customer interaction.
According to Forrester, these are the inhibitors to improving sales, customer satisfaction, and retention:

​The Pega 7 Platform has integrated its powerful predictive and adaptive analytics capabilities directly into Designer Studio. As a result, business people now have the ability to use sophisticated analytics without lengthy training and specialized expertise. Furthermore, these capabilities come with lifecycle governance capabilities that make it easy for business users to set up, create trial simulations, deploy, and roll back changes in a way that is appropriately authorized and controlled. This means that business users can test and deploy strategies without disrupting any ongoing business or IT operations.

Gain visibility with federated case managementFederated case management in the Pega 7 Platform provides organizations with a way to manage cases and processes across multiple, independent applications, while preserving their autonomy, governance, and security. For example, customer service organizations can have a complete view into all of a customer’s outstanding issues across multiple Pega 7 Platform applications, gaining complete process visibility and reporting. Customer service representatives answer all of the customer’s questions and provide higher quality service.
Deliver new capabilities fasterPegasystems' customers know well the business agility benefits to be gained with the unified Pega 7 Platform in today’s rapidly changing business environment. The Pega 7 Platform further improves business agility by enhancing system development speed and accuracy in the three most critical and generally time-consuming areas: getting the requirements right, getting the user experience right, and getting the data right.
Getting the requirements rightAccording to IAG Consulting research, up to 70 percent of IT projects resulted in a marginal outcome or failure.
The top reason was that the requirements and results did not mesh. Pegasystems customers know how DCO (Direct Capture of Objectives) helps them avoid failure by directly converting modeled requirements into finished applications without the usual time-consuming and error-prone process of hand coding.
The Pega 7 Platform has improved DCO capabilities by making Case Lifecycle Management the design center of the product, and by furnishing visual tools that facilitate the accurate capture, realization, and evolution of the full scope of work. It uses a visual language that everyone—business executives, subject matter experts, and IT practitioners—can readily understand. Case Lifecycle Management gives business users a way to define the steps of how work gets done by defining aspects of the “case,” as a set of workflows that needs to be accomplished and a definition of a desired outcome. A case, for example, defines how a bank’s customer-service operations handle a lost credit card or how a health plan cares for a client with a chronic condition such as diabetes.
Case Lifecycle Management provides a way to capture all of the important information about a business process without getting lost or bogged down in the capture of all the details contained in a Business Process Management Notation (BPMN) definition of processes and transactions. Those details are important as well, but they are captured within the context of the high-level case definition, and can be elaborated over time once the high-level case lifecycle is understood. In addition, the Pega 7 Platform Case Lifecycle Management provides the freedom for designers to make changes to the high-level design at any time during the development of a project. Because the high-level design is part of the model, the design and the finished application are always kept in sync.
Case stages are captured within the application documentation, which provides a complete view and understanding of case behavior. The inclusion of Case Lifecycle Management in DCO contributes significantly to these gains because it makes it easy to capture and document the case management requirements of an application.
Another development in the Pega 7 Platform’s dynamic case management capabilities is the addition of an Ad Hoc Case Dashboard. The Ad Hoc Case Dashboard makes it possible to create a new ad hoc case to flexibly organize and facilitate work that is unplanned and unstructured. It is easy to create an ad hoc case, create a task list (with assignments, status, and deadlines), attach content to the case to keep it organized, and optionally configure the ad hoc case for reuse.

Regardless of whether an ad hoc case is created from “My Cases,” Pega Pulse, or a local flow action, they all call the same functions and rules and create the same ad hoc cases. With this new capability, users have a unified way to add new tasks to work already in process, make changes in the way a case is being handled, or even draw new business processes as needed. This speeds up the resolution of work, while reuse allows organizations to quickly promote best practices across the organization.

Getting the user experience right
​A critical component for the successful adoption of an application is getting the user experience right. This requires creating easy-to-use interfaces, incorporating feedback, and revising as needed to ensure users can work efficiently and effectively with minimal training.
As noted earlier, in the Pega 7 Platform, you create the UI once and deploy it on any device, in any locale, in any browser—all without coding. For developers, this saves considerable time and effort and it works across all three mobile experiences, Mobile Web, Pega Mobile Client, and Pega Mobile Mashup.
How much development time does having all of this functionality in the Pega 7 Platform and accessible through the Designer Studio save organizations? When Cap Gemini performed its productivity study on the Pega 7 Platform mobile development capabilities, it found development was 40 times faster than traditional coding techniques. (The study did not even include the Pega Mobile Client and Mobile Mashup capabilities, because they were not available at the time.)
Live UI, another design-time enhancement, allows business stakeholders and developers to collaborate on the user experience interactively from within a running application. With Live UI, the team can adjust layouts (for example, 3-column to 2-column), UI controls (for example, change a link to a button with text), styling (for example, button color), mandatory/non-mandatory field behavior, and field labeling. This enhancement speeds development by allowing adjustment to user screens during DCO sessions for immediate feedback. Built-in governance features control the migration of these changes to production.

Getting the data rightA key component of efficient application development is getting the data model right the first time. According to Aberdeen Research, up to 40 percent of the time spent on an IT project is on integration.
The Pega 7 Platform introduces Pega Live Data, a data integration and management facility that addresses this issue. Pega Live Data simplifies the use of data in processes in the following ways:

• Through declarative rules, it automatically fetches data from systems of record as needed in processes and screens. This means that your processes are not cluttered by work related to the retrieval and preparation of data. A new Data Explorer makes it easier to incorporate data into applications.
• It is much easier to set up the flow of data among clipboard/cases, data pages, and connectors/services.
• The Pega 7 Platform now has the concept of nested data pages, which makes it easier to separate application-specific data management from cross-application data management, making reuse easier.
• The new Data Visualizer provides an interactive way to explore data relationships through an entity relationship diagram-like visualization that shows the relationships among classes that are established by page (object) and page list (object array) properties. Any Pega 7 Platform class displays if it is connected to a data type, including case types and data types. Developers now have an intuitive way to see how data fits into an application. This makes it easier and faster for developers to use the data and modify the application.

Easier third-party application and service integrationThe Pega 7 Platform's new REST integration wizard saves developers considerable time by providing a tool that automatically integrates a REST service into the Pega 7 Platform data page. Furthermore, after this data page has been created, any subsequent team members working on the application do not need to know the details of how the integration was done.
With the most recent updates to the Pega 7 Platform, Pegasystems has introduced SAML SSO to the product, making it easy to provide full SAML 2.0 Single Sign On regardless of whether the application is on the premises or running in Pega Cloud. This new capability saves the developer the time and effort of writing custom Java code to integrate the Pega 7 Platform with enterprise identity management systems.

Product Designer Mike Degatano has assembled a list of guidelines and best practices for developing applications in the Pega 7 Platform. His goal is to help developers create applications that are efficient, sustainable, and guardrail-compliant.
​

• User interface
• Data
• In general

• Choose the right control for each list type:
  • Simple lists. The same distinction (do I need a header row?) applies when you choose between column repeat and dynamic column repeat layouts.
    • If you need a header row, use a grid with a width of 100%. Do not set a fixed width in pixels.
    • If you want columns and automatic filtering options or you want the data sourced directly from a report definition, use a grid.
    • Otherwise, a repeating dynamic layout is preferable.
  • Nesting lists
    • If you need a table with multiple header cells, use a tree grid. But note that tree grids that display large amounts of data can have display and performance issues.
    • For other nesting lists, use a tree, which is much simpler and can display huge amounts of data with no performance issues.
• Using a section versus nesting a dynamic layout. For performance and maintenance reasons, minimize the number of sections that you create.
  • Use a section if:
    • You plan to use it in multiple places.
    • Its contents need to be refreshed from the server more often than the content around it.
    • The data requires a table-based layout such as grid, tree grid, or column repeat but you want to put it in same layout as the rest of the UI, perhaps to share a container format, style, or header.
    • Its content uses a different step page from the UI around it.
  • Otherwise, nest a dynamic layout.
• Only use a top-level clipboard page directly in your UI if:
  • It is a data page or system page, and you are displaying its data in read-only form.
  • It is an editable data page that you are using to support a stand-alone user input form.
  All other references to top-level pages that are unrelated to the primary page (or undefined pages) should be considered technical debt. This is especially true in the UI regardless of whether the page is used as read-only or editable.
  
• Do not overwrite secret UI extension points. Do not overwrite Secret UI extension points at your class, which changes the default modal template for your class and all classes that inherit from it. Secret UI extension points include sections and activities such as pyModalTemplate, pyGridModalTemplate, pyPostGridUpdate, and pyOverlayTemplate.

You can solve one use case by overwriting a Secret UI extension point but doing so can cause maintenance issues. In addition, your change affects every UI interaction of that type in your process. Changing the templates to fix a problem in a modal dialog box is like rewriting the browser because you do not like how a website is displayed.
Instead, use built-in parameters to change the template or behavior for your particular use case.

• Use set value to set flags. Use case: you have a property .pyIsThingVisible. Put the property in a hidden input field in the UI and use "set value 'pyIsThingVisible = true" (or false). This is lighter weight than using "Run data transform pzSetIsThingVisible" (and creating and maintaining the data transform).
• Using Refresh When and Refresh Other Section. Use Refresh When whenever possible, especially for read-only references that need to stay in sync with data on the server, as it declares dependencies ("This section needs to be updated when .x changes"). When this is not possible (for example, you have editable references that get updated based on other input or based on untrackable input such as button clicks), use a Refresh Other Section targeted refresh.
• Avoid Refresh section. Refreshes interrupt the user experience. The user has to wait, the screen seems to hang until the section refreshes, and after the refresh is done, the user has lost focus and has to manually get back to the original screen. It is much better to use client-side interactions by using change tracker whenever possible. For example, rather than refresh a section with a pre-processing data transform, call a data transform or use set value and set your visibility conditionals to evaluate on client.
  • Do refresh a section when:
    • Property values have been updated on the server and the new values need to be reflected in the UI.
    • An action that causes a change to more than one property and occurs only on the client, such as deleting a row, needs to be submitted.
    • Parts of the UI need to be removed from the DOM because of other input.
  • Do not refresh a section when:
    • You need to submit user input (use post value instead).
    • You need to call a data transform or an activity after a user action.
    • You need to recalculate visibility, enabled/disabled state, or read-only state. Select the evaluate on client check box next to the expression field.
  • Judgment calls:
    • You have a complex expression to set visibility, enabled/disabled, or read-only state requiring a when condition. Consider using a declare expression to provide a value for a property and conditionalize on changes to that declare expression.
    • You have to handle style changes based on value changes.
    • You have to validate input and potentially show messages related to various properties. Note that validation provided by the controls, and a validate rule on the flow action, should cover most such situations.
• Combine server actions. Every action in an action set that makes a call to the server (run a data transform, refresh a section, and so on) is a separate Ajax call that affects server resources.

Data

• Use the tools at your disposal. There are two kinds of data in the application: user input and everything else. Any piece of information used in the process or on the primary page that the user did not give you is non-user input data.
  When you work with non-user-input data, you have five major tools at your disposal:​
  • Read-only data pages (see below for editable data pages) take a fixed set of scalar parameters and load any piece of complex data from them.
    • Obvious examples:
      • Instance from a database based on keyed access.
      • Instance list from a parameterized report.
      • Connector to pull in information from a remote location.
    • Less obvious examples:
      • Taking in a WSDL and parsing out important pieces.
      • Taking in XML or JSON data and creating a nested treeview list from it.
      • Taking in XML or JSON data and turning it into a matching clipboard page or putting it through an XML Parse.
      • Taking in a URL and parsing it into its significant components.
      • Taking in a generation request page and obtaining an evaluation of rules to be generated if the request is valid.
      • Creating a page of simulation data based on the parameters provided to simulate a connector.
      • Taking in the Applies To class and the type of the record that you want to create and returning a list of rulesets that are valid for that context.
      • Basically, if you need a page or object loaded with data, use a data page. It will work for your use case.​
  • Declare expressions define a relationship between the value of a single scalar property and a list of other scalar properties on the work page. When you specify an expression involving one or more properties on the top-level, parent, or primary page specified, the property always contains the value of that expression. You can set the value of a property on every page of a page list this way.

Your expression can involve multiple when conditions and functions, giving you a powerful tool for populating property values.
Examples:

• The display version of a URL is always the normal URL without the query part.
• The display version of a URL is always the normal URL without the query part.
• The default name is always set from the service name without the namespace.
• The branch ruleset is always <ChosenRuleSet> + "_Branch_" + <ChosenBranch>.
• The authentication profile name for each method is equal to the authentication profile name selected for the workspace.
• If @isAnIPAddress returns false, the data source name equals @getResourcePaths(.pySourceURL, 3); otherwise it equals the Integration name

• Auto-populated properties define a relationship between the value of a single page or page list property and a list of other scalar properties on the work page. You specify a data page to construct the page or page list and the properties to use as parameters to determine the data page's value. This is functionally the same as using a data page directly. So why would you use an autopopulated property instead of just using the data page?
  • Maintainability. If you find yourself repeatedly referencing a data page and passing in the same values as parameters, make an autopopulated property. That way, if later you change the data page or any of the properties, you will not have to hunt all over to find all the places to make the change.
  • Understandability. Non-user input data loaded from user input can still be vital to a user's understanding of how the process works. The data model should lay out exactly what the process needs, and that includes loaded data.
  • Keyed page lists. This feature is extremely powerful, and in the Pega 7 Platform, the only way to leverage it is through autopopulated properties. See Instantly access embedded pages in a data page.
• There are three types of data transforms: Data transforms support complex data manipulation. If you move data around in your application, you can do it with a data transform (in some cases you may also need to make and use functions).
  • Maps define a translation between two different pieces of data. For example, when mapping the work page to a more compact generation request object you should use a data transform. See Pega-DataModel-DataSources.pyCreateGenerationRequest for an example.
  • Models are used to initialize an object based on its state. For example, it is a good idea to have a pyDefault and a data transform in between the steps in a flow. The first pair sets the object's initial state, and the others set the object to its initial state for the each step.
  • Setting optional relationships is a replacement for declare expressions when they cannot be used. Declare expressions cannot be used to set editable fields. You can have a field set with a declare expression or set with user input, but not both. So if you have a field that is always initially set to .A + " " + .B when .A or .B is set, but the user has the option to customize the field's value, you can't use a declare expression. You need to create a data transform and call it as necessary, because a declare expression cannot do it for you.
• For data management, activity usage should be primarily restricted to persistence. Creating, updating, and deleting data require using an activity. Otherwise, use activities sparingly in your data layer. While a few situations require using an activity, such as trying to source a page or page list when there is no other way to define the parameters as a set of scalars, in most other cases, you can use specific rules. There are also methods to pass some types of complex objects as parameters. See D_EvalResults for an example with data integration.
• What about editable data pages? Functionally, they are almost the same as read-only data pages. However, they serve a different purpose: editable data pages provide a way to modify data that is tangential to what you are working on.
  • Examples:
    • The user must select a data record to use in the process. You give them a way to view, and if they want to update and save, the data record in a modal dialog box. This has no effect on your process, because you reference the record by name and the details of that data record are not part of your work object. The modal dialog box should use an editable data page.
    • Your process asks you to select users from your contacts list. It gives you a way to view and edit your contacts, if you want, in a modal dialog box. Again, this has no effect on your process because you only store the reference to the contact, not the details of the contact, in the work object. The modal dialog box should use an editable data page.
    • Your process gives users an investigative tool to explore what they are creating (for example, a testing tool). If they want, users can save snapshots of their configuration and the work page can reference those saved snapshots. Working in this tool has no effect on the process because the details of the tool's configuration are not stored in the work object. This tool should use an editable data page.
    • A rare example: a piece of the portal is mutable, and its details need to be accessible to all processes and actions in that session. This requires a requestor-level editable data page. An example in Designer Studio is the Recent Items explorer.
• Examples of how not to use an editable data page:
  • Storing information that is part of your process outside of the work page.
  • Storing changes to tangential data to be persisted as part of the original process.
• Define your data model. Capture every piece of data your process needs with a meaningful property name.
• Simplify your data model. Fred Brooks wrote, in The Mythical Man-Month, "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures and I won't usually need your code: it'll be obvious." This should apply to us as we work in the Pega 7 Platform. A developer should be able to look at your class in the Application explorer, or open up the clipboard and look at the primary page, and it should just make sense. The developer should not have to dig into the code to understand what is going on in the application.
• Do not duplicate properties if you can avoid it.
  • If multiple classes use a property, define the property once where it is accessible to all classes that need to use it.
  • If one of two classes that need to use the property do not share a parent (for example, one is Embed- and the other is not) you can copy the property; but make sure to use the exact same name.
• Avoid copying data.
  • Data the process uses should exist in only one place. In the Pega 7 Platform, that means in a single property.
  • If the data appears in many places, use the same property in each of those places. Do not copy the data from one property to another property.
  • If user input has a cascading effect (setting a value in one place defaults a number of other values), then it is all right to copy data if the effect is one-directional. In other words, it is only all right to copy if you can define using something like a declare expression. If two properties have a circular dependency then something is wrong.

Direct Capture of Objectives (DCO) is the set of tools designed to capture and tie business objectives, project goals, requirements, and use cases to actual implementations.
​
Rules and tools include:

• Application Profiler
• Application Accelerator
• Application Document Wizard
• DCO Enablement Wizard
• Application Use Case rules
• Application Requirement rules

Business rules whether stated implicitly or explicitly contains all your organization business knowledge. A collection of your organization business policies, constraints, Computations, reasoning capabilities etc.

A business rules engine is a software component that allows business rules to be recorded in a non-procedural, non-programming form, and uses advanced software techniques to compute the consequences and results of rules. The PegaRULES component of PegaRULES Process Commander provides a powerful rules engine supporting business process management, and other applications through services. Developed in Java, highly scalable and reliable, PegaRULES supports declarative rules, multithreaded execution and a large number of industry interfacing and standards. The business rules engine can be embedded or called from another system using Service JSR94 rules.

BRE, BAM, Integration Engine, Interfaces for Development and Maintenance. 

1) Difference between Pega BPM Suite and other BPM Suites is Business Rules Engine and Business Activity Monitoring (BAM)

2) Many Process Commander applications provide business process management and automation through six functional capabilities, informally known as the Six R's:

• Receiving — Accepting and capturing the essential data describing work from multiple sources in multiple media and formats, from keyboards, scanners, and external systems.
• Routing — using characteristics of the work and knowledge about the workforce to make intelligent matches and assignments.
• Reporting -- providing real-time visibility of work in progress, work completed productivity, bottlenecks, and quality.
• Responding — Communicating status, requests for information, and progress to the work originator and to other people involved in the work, by email, fax, written mail, and other means.
• Researching -- Accessing external systems and databases through connectors to support analysis and decision making.
  
• Resolving -- through automated processing and automated support of users, completing the work and updating downstream systems promptly. 

BPM is a Management Philosophy. It focuses on Business Processes and Sub-Processes of an Industry with the behavior of Systems and Individuals within it. It models the processes and subprocesses visually and uses advanced Information Technologies to solve the business problems. It strives for better performance, easy to change and quality software.

• Built for Change
• Time to Market

BPM is about people and the way they work together (their business process) and their performance objectives.