Difference between revisions of "Implementing versioning"

From PegaWiki
Jump to navigation Jump to search
Tag: Visual edit
Tag: Visual edit
Line 51: Line 51:
Β 
The auditing needs of the organization should be kept in mind when trying to enhance the versioning logic by the implementation team. The centralized module for versioning also means that the changes would be applied to all the entities. One of the most common inputs to the design for versioning is the process by which the plans change from year to year, and the compliance requirements on the reporting. The overall stage in which the updates happen also be kept in mind, and the versioning configuration adjusted accordingly. If the implementation team wants to prevent updates to the plans in the production stage without changing the version, the following configuration on the PCS configuration page at AgileStudio -> Configure -> Product Composer System -> Configuration can be updated. Β 
Β 
The auditing needs of the organization should be kept in mind when trying to enhance the versioning logic by the implementation team. The centralized module for versioning also means that the changes would be applied to all the entities. One of the most common inputs to the design for versioning is the process by which the plans change from year to year, and the compliance requirements on the reporting. The overall stage in which the updates happen also be kept in mind, and the versioning configuration adjusted accordingly. If the implementation team wants to prevent updates to the plans in the production stage without changing the version, the following configuration on the PCS configuration page at AgileStudio -> Configure -> Product Composer System -> Configuration can be updated. Β 
Β Β 
βˆ’
== Results ==
Β 
Β 
Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.
Β 
Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.

Revision as of 14:41, 29 January 2021


Curator Assigned shahp@pegasystems.com
Request to Publish
Description Implement versioning
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 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Versioning in PCS[edit]

In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycle. Workflows of these entities generally progress at different times in discrete phases. During a phase, user might need to allocate a different set of data or enforce different business rules. In these situations, user can represent the changes to an entity in time blocks. Each time block of an entity is a version.

The time block used in PCS are effective dates and these dates drive versioning for all entities in PCS.

Users can find detailed explanation about how versioning works in PCS at https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/versioning

What affects versioning[edit]

On the metadata screen of all entities, we have two properties

1) Effective date

2) End date

These two dates are the core properties driving the versioning logic in PCS out of the box.

Whenever the user changes any one or both of these effective dates, the PCS application automatically creates a new major version for the new entity. If the effective dates are not changed, the application would create a minor version. For example

  1. User A creates a new e-visit benefit. Version 01-01 is assigned by the application.
  2. User A moves the benefit to the Dev-Approved status. The benefit is now in the Dev Approved work queue and is available in the application’s search list with the Dev-Approved work status.
  3. Later, User A opens the entity in the application, and clicks Save as new version.
    • If User A clicks Next without changing the effective date or end date or both, the next minor version, 01-02, is assigned to the e-visit benefit.
    • If User A clicks Next after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered.

Extend versioning in PCS[edit]

There is a centralized data page "D_NewVersion" found in the ruleset PegaHC-USA-PCS:08-01-01 which drives the versioning for all entities in PCS.

User can find more details on use of data page at https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-declare-/rule-declare-pages/data-pages-con.htm

If the implementation team wants to change the default versioning logic, they can include any other property from the implementation layer or base PCS layer to the above data page.

There could be many scenarios under which the implementation team may want to enhance the versioning logic, like having open ended plans or controlling the versions of plans for a particular calendar year, or having the versioning for plans for a particular line of business or may be add versioning based on input requests from sales automation system.

Design inputs[edit]

The auditing needs of the organization should be kept in mind when trying to enhance the versioning logic by the implementation team. The centralized module for versioning also means that the changes would be applied to all the entities. One of the most common inputs to the design for versioning is the process by which the plans change from year to year, and the compliance requirements on the reporting. The overall stage in which the updates happen also be kept in mind, and the versioning configuration adjusted accordingly. If the implementation team wants to prevent updates to the plans in the production stage without changing the version, the following configuration on the PCS configuration page at AgileStudio -> Configure -> Product Composer System -> Configuration can be updated.

Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.