Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Approving an event code configuration

Updated on August 31, 2021

New event codes or changes to existing ones are sent for approval to the System manager work queue. Authorized users can then approve these items.

Most event code approvals will follow the standard approval actions, but due to the versioning, some situations present alternative buttons in the approval screen. The available actions are detailed in the table below:

ScenariosEvent code actionsApproval screen information
Approval date is before version start dateCreate new event code, create new version, edit versionApprove, Reject, and Send to originator buttons are displayed.
Approval date is after or same date as the configured version start date Create new event codeApprove system date, Approve requested date, Reject and Send to originator buttons are displayed.
Approval date is after the configured version end date Create new event code, create new version, edit versionReject button is displayed. The configured version is already in the past.
Approval date is after or same date as the configured version start date Create new versionApprove system date, Reject and Send to originator buttons are displayed.
Approval date is after or same date as the configured version start date Edit VersionApprove system date and Reject buttons are displayed.
Deactivate date and the original version end date are in the pastDeactivate event codeReject button is displayed. The configured end date is in the past and the event code is already inactive. An informational alert is also displayed.
Deactivate date is in the past and the original version end date is in the futureDeactivate event codeApprove and Reject buttons are displayed. On approval, the system date is used as the version end date. An informational alert is also displayed.

The changes to the requested version start or end dates for the event code is required as processing is performed utilizing the system date. This will ensure that any previous versions are end dated appropriately and any new configurations can take effect when required. When the approved system date is utilized, the new event code version start date will reflect the system date, and if a previous version exists, it will have an event code version end date of the system date minus one day.

When event codes have a configuration due to start today, any claims processed against a previous configuration or instance where this event code was not configured may need to be reprocessed.

This is identified as a note in the screen shot below:

Note: best practice for implementing event code configurations is to ensure the start date for the version is in the future.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us