Configuring and extending stages, statuses, and work queues

Curator Assigned	shahp@pegasystems.com
Request to Publish	Yes
Description	Configuring and extending stages, statuses and workbaskets in PCS
Version as of
Application	Pega Product Composer for Healthcare
Capability/Industry Area	Healthcare

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.

When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

The Pega Composer for Healthcare application provides a robust capability to manage various entities such as benefits, networks, product templates, products, and plans. Out-of-the-box, PCS provides various lifecycle stages for each of these entities. Within each stage, the application also assigns predetermined statuses to these entities as they progress through each stage. And to complete the infrastructure setup, PCS also provides several workbaskets where these entities are held for processing.

Pega-provided case management features are extensively used to achieve this feature.?? which feature? life cycle Management??? Each PCS entity, for example benefit and product template, undergoes this life cycle process. For example, a typical healthcare benefit configuration undergoes various stages in its life cycle before it is available for consumption in the actual marketable and salable health plans. This progression of a benefit or any PCS entity through various stages typically starts with a concept or idea. It traverses through various internal and external reviews and approvals before it is available in production (salable). It is finally retired when it is no longer used. Similarly a product template, product, or plan undergoes this life cycle.

Rather than being a linear, serialized process, a plan or product configuration is made up of many processes, tasks, policies, and supporting content. Depending on the context of the plan or product, elements and the way that work is accomplished change. ?? what does this mean???? Furthermore, a plan as a whole, continues to change throughout its life cycle to due both internal and external events. what does to due mean?? Adding to the challenge, there are often several configurators, product managers, and other internal and external parties who collaborate on any given plan or benefit configuration.

Therefore, this customizable, stage-based, life cycle management provides better control over the business process and improves the consistency, effectiveness, and visibility of process-handling, thereby decreasing cost and improving quality.

Life-cycle, stage configurations such as changing the stage names, skipping the stages, jumping across the stages, and skipping approvals are business-friendly. Business users can tweak when rules, decision rules, and flow rules. Is the flow link the correct reference for the users? Is this OK to reference these links? These are easily configurable and extendable.

Lifecycle stages, statuses and workbaskets

Stages in PCS

You can customize each of these stages and add more stages by using the extensions provided.

For example, you can move benefits from Development to Production after approval and eliminate the Implementation stage, thereby reducing the overall time for configuring each entity. For more details on the various stages in PCS, see Life cycle management.

You can also skip a specific stage from the life cycle for all entities by using the SkipDevelopment or SkipImplementation configuration rules. You can access these configuration rules by clicking Configure > Product Composer System > Business Rules in Dev Studio.

Statuses in PCS

Out-of-the-box, PCS provides detailed statuses for each of the entities. The statuses are based on the stage of an entity. For example in the Development stage, each entity will have the statuses of Dev-Initiation, Dev-PendingApproval, and Dev-Approved.

The statuses of the PCS entities also drive many of the validation and processing rules. For example, for the flattening process, you can control which entities to flatten based on the status and stage of the entity.

Any additional statuses can also be added by the implementation team. ??? Is this the correct link for them to create new statuses???

Workbaskets in PCS

Several out-of-the-box workbaskets are available in PCS. Having a foundational knowledge about them is very important for the implementation teams. As shown in the Life cycle stages image above, the respective entities move to different workbaskets based on their stage and status. In the following table, each column describes the workbaskets in the stage.

PCS workbaskets based on stage

Development	Implementation	Production	Retirement
Dev_Initiation	Impl_Initiation	Prod_Initiation
Dev_PendingApproval	Impl_PendingApproval	Prod_PendingApproval	Retire_PendingApproval
Dev_Approved	Impl_Approved	Prod_Approved

Some other out-of-the-box workbaskets are listed below. All these workbaskets can be accessed from the Manager portal.??? I did not see these. Where are they? Also i tried searching for some of these to find the exact way they are written (underscores etc) and they didn't show up. Where should i be looking?

Other PCS Workbaskets

Sr No	Workbasket	Description
1	Pending Auto Flatten	Workbasket to hold all the flattening jobs
2	Document Approved	Workbasket where all the approved SBC documents are stored
3	Custom work plan queue	Workbasket where incoming requests for custom plans are held (input via API)
4	Entity save failed	Workbasket to store the entities that could not complete the save process
5	PCS product admin	Workbasket with complete list of products
6	Pending import	Workbasket to store the list of entities which are pending the import process
7	Plan update failed	Workbasket where the plans that could not complete the update process are stored
8	Update pending approval	Workbasket where the entities pending approval are stored

You can add more processing for entities after the entities are moved into one of these workbaskets. For example, if the business team wants to run any of the quoting process, they can run it on any one of these workbaskets.

Extension for implementation teams

Having a clear understanding of the out-of-the-box stages, statuses, and workbaskets is a must for any member of the implementation team. Knowing how to make changes by leveraging the extension rules allows the implementation team to rapidly customize PCS to meet the needs of the business. Out-of-the-box, PCS provides the following decision rules to facilitate the customization. You can access these rules by clicking Configure > Product Composer System > Business Rules in Dev Studio.

For example, the business might want to add a workbasket, such as Pending-Quote, to PCS before moving the plans to production. By using the above decision rules, the implementation team can quickly re-use one of the workbaskets or add a new one.For more details about updating workbaskets (also known as work queues), see Creating a work queue .

Similarly, you can rename or remove any of the stages from the flow by using the Customize stage names decision rule. For example, if the client team prefers the name Ideation instead of Development, the team can change the name by using the Customize stage names decision table as shown below. I can't change the size of the image. This is too big...goes beyone the right text border. Can you change it? Maybe only show the table part?

For more details about changing status, see Standard rules and extension points.

The first level of organization of the tasks that are required to complete your business process. By providing stages, you organize work into logical phases that users of your application follow to reach an outcome. Stages visualize milestones or significant events in your business process and can also indicate a transition of work from one person to another. For example, if your business process is to review job applications, you can create Submission, Review, and Approval stages, each of which includes a different set of actions and is performed by a different person. Stages that are necessary to resolve a case through the basic, default path are called primary stages.

In a Microjourney™, stages are the milestones that leads towards an outcome.

A business solution that automates workflows in your organization. Multiple, unrelated applications can be hosted in the same system. You create an application by running the New Application wizard.

The first level of organization of the tasks that are required to complete your business process. By providing stages, you organize work into logical phases that users of your application follow to reach an outcome. Stages visualize milestones or significant events in your business process and can also indicate a transition of work from one person to another. For example, if your business process is to review job applications, you can create Submission, Review, and Approval stages, each of which includes a different set of actions and is performed by a different person. Stages that are necessary to resolve a case through the basic, default path are called primary stages.

In a Microjourney™, stages are the milestones that leads towards an outcome.

A method of delivering goal-oriented results by handling business cases from start to a resolution and combining human actions with digital automations. In case management, you use data and people that are involved in a business process to visualize and model work, so that you can prepare a set of actions that lead to your objective. For example, you can model a process of approving candidates after reviewing job applications, from collecting documents from a candidate, through the job interview, to the final approval.

A capability that you implement in your application. By defining features that are linked to rules and work items, you can improve the traceability of capabilities to their respective implementations.

The actions that are taken during a stage, in parallel or one after another. Processes can include assignments, automations, decisions, and sub-processes

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

The first level of organization of the tasks that are required to complete your business process. By providing stages, you organize work into logical phases that users of your application follow to reach an outcome. Stages visualize milestones or significant events in your business process and can also indicate a transition of work from one person to another. For example, if your business process is to review job applications, you can create Submission, Review, and Approval stages, each of which includes a different set of actions and is performed by a different person. Stages that are necessary to resolve a case through the basic, default path are called primary stages.

In a Microjourney™, stages are the milestones that leads towards an outcome.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

1) In user portals, a "team" is equivalent to a "work group". 2) One or more associates who work semi-autonomously on recurring tasks or towards a common goal. In a Pega Workforce Intelligence hierarchy, departments are comprised of teams. (Defined by the WFI team)

An interface that provides users with an organized set of work tools. Users navigate the application, collaborate, and complete work assignments mainly through portals. Typically, you create a separate portal for each user group within your application. For example, you can create a portal for regular employees, and a separate one for their managers. Most portals contain a navigation menu that leads to various pages and dashboards, as well as a menu for creating new work items. Additionally, portals might also include widgets that improve work efficiency. For example, you can design a portal that has a widget for frequently used reports, which helps managers save time and oversee their projects.

This is a deprecated term for what is now known as the work queue.

A piece of data that can be extracted from text, including names, locations, amounts, IDs, and so on.

This is a deprecated term for what is now known as the work queue.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

A table that consists of one or more rows that contain test conditions and a result to return. Evaluation proceeds from top to bottom; when the conditions in all cells in a row are true, the result of that row is returned. If no row returns a value, the table provides the Otherwise row result. Decision tables are instances of the Rule-Declare-DecisionTable class.