Data page errors in a case life cycle
Help users resolve data page errors that they might encounter while they run a case. For example, you can present users with error messages that quickly guide them to a resolution with minimal disruption to the case.
To understand your options for handling data page errors in common situations, review the following guidelines:
- Consider whether the case can handle the error automatically. For example, if you
configured a case with a Twitter gadget and the feed displays an error, the user can
still proceed through the case without the Twitter feed data.
Additionally, if you configured an alternative data source from which the case can retrieve data, the case can proceed without user intervention. For more information about adding alternative data sources, see Configuring multiple data sources for a data page.
- Consider whether the user can resolve the error. In this situation, present an error message in the case that provides clear instructions on how to resolve the error.
- If the case cannot handle the error automatically, or if the user cannot resolve the error and cannot proceed with the case, you can present a message that instructs the user to contact an administrator. Route the assignment to the FlowProblem flow so that a system administrator can review the problem.
Common data page errors include the following examples:
- Invalid authentication
- This error occurs if you make calls to an external system by using invalid
credentials. Typically, in Pega Platform, an
administrator configures client credentials authentication in the data page
for all the users in the system. For example, if the credentials are
expired, an administrator must update the credentials in the data page. In
this scenario, you could configure the following error handling:
- Present the user with a message that states that they cannot access
the system and to contact an administrator.
You can also configure the case to automatically contact the administrator.
- Route the case to the FlowProblem flow so that an administrator can review the problem.
For more information, see Updating connections and field mappings for a data object.
- Present the user with a message that states that they cannot access
the system and to contact an administrator.
- Invalid authentication might also occur if you are using the following
authentication types:
- Token-based authentication
- If your token expires, and your application has a token refresh
mechanism, the user can refresh and try the action again.
Otherwise, the administrator must manually regenerate the
token.
For more information, see Enhanced refresh token strategy.
- User-interactive authentication (such as OAuth 2 with the auth code flow)
- Present the user with a message that states that the user must
authenticate and provides authentication instructions. After the
user authenticates, they can refresh and try again.
To handle this scenario, you can add an external web component and configure an authorization section to connect to an external application at run time. For more information, see Creating an External web component.
- Permission denied
- If the system successfully authenticates the user but they do not have
permission to do a specific task, you can implement the following error
handling options:
- Present an error message that notifies the user that permission is denied, and an administrator must grant permission.
- Implement an automatic error handling approach, for example, assign the task to the user's manager for review.
- Invalid inputs
- This error occurs if the user provides an invalid input that the service to
which the data page is connected cannot accept. For example, if a user
submits a credit card application without completing the required
CVV field, they must enter the CVV and submit the
form again. In this scenario, you have the following options:
- You can present an error message that clearly states why the input
is invalid and what the user needs to do to resolve the error.
For cases that are using save plans to persist data updates from the case lifecycle to external systems, configure a validate rule to prevent Pega Platform from sending invalid requests to the remote system in the first place. For more information, see Creating a save plan for a data page in Dev Studio.
- If the user cannot resolve the invalid inputs error, route the case to the FlowProblem flow so that an administrator can review the problem.
- You can present an error message that clearly states why the input
is invalid and what the user needs to do to resolve the error.
- The system is unavailable
- The way you handle this error depends on the data that the user needs to run
the case. For example, if a Twitter feed cannot update, an error message
that states that the feed is temporarily unavailable is likely sufficient.
However, if the system that the data page calls to retrieve the customer's current account information is unavailable, the case cannot proceed. In this example, an administrator must review the error.
The system can also be unavailable if an HTTPS certificate is expired. An administrator must resolve this error.
- Conflicts
- Conflicts are errors that occur specifically for cases configured to use
save plans. For example, as part of a Job applicant case, you updated an
applicant's address. But someone also updated the applicant's address on the
remote system. The next time you load the case, you will have a conflict
because the address in your case is different from the address in the remote
system. You can handle conflicts in the following ways:
- If you are aware of situations that could cause conflicts in your
case, if possible, automatically resolve the conflict by using logic
in your case process.
For example, you updated a customer’s address on their credit card account by using a Change-Address case. The Change-Address case is the only way to update a customer’s address. You then call an API to save the customer’s credit card account information. The API responded that there is a conflict because the account data was updated prior to you updating the customer's address. You might not know what additional information was updated, but you know that the address can only be changed in a Change-Address case. To resolve the conflict, get the latest version of the account, update the address fields with the new address, and resubmit.
- If a user can resolve the conflict, create an alternate stage in the
case in which the user handles exceptions that occur in the case
life cycle. Present the user with details of the conflict, such as
the old and new data for comparison. The details should describe the
tools the user needs to resolve the conflict and then resubmit the
request.
For more information, see Creating an alternate stage.
- If you cannot use automated logic or if the conflict is too complex for a user to resolve themselves, route the case to the FlowProblem flow so that an administrator can review the problem.
- If you are aware of situations that could cause conflicts in your
case, if possible, automatically resolve the conflict by using logic
in your case process.
Previous topic Updating data in a case by using savable data references Next topic Savable data pages