Difference between revisions of "Implementing versioning"

From PegaWiki
Jump to navigation Jump to search
(Initial creation 1-27)
Tag: Visual edit
(1\28 update)
Tag: Visual edit
Line 16: Line 16:
  
 
=== Versioning in PCS ===
 
=== Versioning in PCS ===
Describe what you try to solve with this design pattern.
+
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  ===
 
=== What affects versioning  ===
Provide a business example to help users understand the objective.
+
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.
 +
 
 +
There is a centralized
  
 
=== Design inputs, how to plan versioning and updates ===
 
=== Design inputs, how to plan versioning and updates ===
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
 
 
 
=== Extend versioning in PCS ===
 
=== Extend versioning in PCS ===
What do individuals need to know to achieve the outcome? What do individuals need to know to achieve the outcome? Enter the precise steps to guide the user to achieving the desired outcome. Remember to always state where in the software the user must perform an action, before giving the action.
+
There is a centralized data page "D_NewVersion" which drives the versioning for all entities in
 
 
If “How To…” documents exist for specific configuration procedures please link (using the url) to those assets on the community **
 
  
 
== Results ==
 
== Results ==
What do you expect the user to see or be able to do after they complete this design pattern?
+
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:16, 28 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.

There is a centralized

Design inputs, how to plan versioning and updates[edit]

Extend versioning in PCS[edit]

There is a centralized data page "D_NewVersion" which drives the versioning for all entities in

Results[edit]

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.