Portal configuration

Each pre-configured role in SDAA has access to specific portals that present relevant information to help users make informed decisions. The application determines which portal a user can access based on their assigned operator access group. For example, back-office users see only the web portal, while customer service representatives (CSRs) access only the interaction portal.

With the Developer portal that includes App Studio and Dev Studio, you can create and update rules. This portal serves as the development environment for the agentic automation features, and ensures that the application can be tailored to meet specific organizational requirements while maintaining the core functionality of the dispute resolution process.

The following figure shows the Developer portal in App Studio:

The following roles typically use the developer portal:

• System administrators
• Security administrators
• Developers
• Business analysts

Access to this portal requires membership in the DisputeSysAdminIssuer access group.

The Interaction portal functions primarily as the Customer Service portal built on the Pega Customer Service™. CSRs use this portal to capture customer information during the initial contact.

The following figures show different views in the Interaction portal:

Key features:

• Captures customer entry information.
• Records details of the dispute during initial customer contact.
• Serves as the first point of interaction in the dispute resolution process.

CSRs who handle calls or chats from customers use this portal exclusively.

The Web portal serves back-office operations in the dispute resolution process. After CSRs capture case information through the interaction portal, the system routes these cases to the back-office dispute department.

The following figures show different views in the Web portal:

Key features:

• Provides tools for validating customer complaints.
• Offers features to determine fund recovery possibilities.
• Includes operations for recovering disputed funds.

Back-office agents use this portal to process disputes after initial capture. These agents differ from customer service agents in that they focus on dispute resolution rather than customer interaction.

With the Data Portal that is included in the Pega Common Data Model (CDM), you can upload sample data, experience the model by using the data, and perform quick updates within a development environment. Although the primary objective of the Data Portal is to help you develop applications more quickly, you might find that portions of the portal help you to implement your own user interface.

The following figure shows the Data portal:

Key features:

• Enables users to upload sample data to experience the model and perform quick updates within a development environment.
• Provides functionalities that assist in implementing custom user interfaces.
• Allows users to view and manage entities and data objects for easy access to default data objects.

SDAA offers flexible integration options with external systems:

• Data Integration: Understanding how applications connect with data sources is essential for successful implementation. The application relies on the Common Data Model, which serves as the transaction record for the application. When moving to production, organizations continue to use their existing systems to maintain transaction records. These production systems require integration with the Common Data Model before the application can function in a live environment. Developers can establish this connection through two methods: directly importing the data or creating pathways using external APIs that bring information from existing systems into the application. This integration forms a critical bridge between the organization's established data infrastructure and the application's operational requirements.
• API Connectivity: Effective integration with external card transaction systems relies on well-designed connectivity solutions. Most organizations rely on Application Programming Interfaces (APIs) to establish and maintain connections with their card transaction systems. These APIs create pathways that allow data to flow between different software environments. When implemented correctly, these connections enable organizations to receive transaction information from external sources in real time. The downstream connections that form between systems ensure that transaction data moves efficiently from the source system to the application, creating a seamless flow of information that supports critical business operations.

To maintain security and operational efficiency, SDAA implements a role-based access control framework:

• Each operator receives a specific access group assignment that determines which portal they can access.
• Back-office users see only the Web portal.

The following figure shows the Web portal access:

• CSRs access only the Interaction portal.

The following figure shows the Interaction portal access:

• Administrators can have access to multiple portals based on their responsibilities.

This structured approach ensures that users interact only with the tools and information relevant to their specific role in the dispute resolution process.

Implementation of SDAA can involve various teams:

• Pega consulting services
• Partner organizations
• Internal bank teams with Pega expertise

The portal configuration in SDAA provides a tailored experience for different user roles involved in the dispute management process. By understanding how these portals function and interact, organizations can effectively implement and utilize this solution to streamline dispute resolution, improve customer service, and ensure regulatory compliance.