Discussion
Pegasystems Inc.
US
Last activity: 19 Jun 2017 9:47 EDT
Ask the Expert - Rules Best Practices with Ken Marin
- Follow the Product Support Community's Community Rules of Engagement
- This is not a Live Chat - Ken will reply to your questions over the course of this two-week event
- Questions should be clearly and succinctly expressed
- Questions should be of interest to many others in the audience
- Have fun!
Pegasystems Inc.
US
Some of the topics we can discuss are:
- Making your features extensible so that they are "future proof".
- The best way to add call-outs to your APIs.
- When should APIs clean up pages and when should they leave them.
- How can you tease apart two rulesets or features that are interconnected so that one can be made to build upon the other.
- Naming conventions.
- What class your APIs should live in.
Cisco Systems
US
Hi Ken,
We implemented Pega about four years ago. We have about 10 different applications across our organization. We have recently begun implementing Pega Customer Service for a new application. We are finding that many of the legacy work types and controls will be needed in the Customer Service portal.
We are really interested to know how best to provide access to the legacy tools without agents needing to switch apps (in essence creating swivel-chair approaches within Pega itself).
Rebuilding all of the legacy functionality in Pega Customer Service would be very costly at this point. Unfortunately much of the legacy work was created in implementation layers. So my question is: would it be effective to create an API integration between Pega CS and our legacy applications in order provide the seamless experience our agents need? Can we retrofit Pega API on the legacy apps? Any rules of the road or potential pitfalls with this approach?
Thanks!
Phil DeGuzman
Cisco Systems
Pegasystems Inc.
US
Hi Phil,
The standard approach to integrating different Pega applications across an organization is to leverage our FCM/FCMR capabilities. Are you familiar with that?