PegaWorld 2025: RBC "PegaForce": Transforming Advisor Experience Through Pega and Salesforce Integration

PegaWorld 2025: RBC PegaForce – Transforming the Advisor Experience Through Pega and Salesforce

Good afternoon, everyone. Thank you for joining us here today. Welcome to the session hosted by Rohit Gupta and Becky Meisenheimer of RBC to discuss how they've used integrated their Pega servicing application to Salesforce, as they call Pega force. I think we all really like that name a lot. They started this transformation in 2023, and actually we're at PegaWorld 2024 last year to talk about how this integration is helping their firm become more efficient and have more transparency internally.

And there they did such a great job that they are one of the very few speakers to be invited back the very next year to talk to us again about how this transformation journey is continuing. So welcome Becky and Rohit and I'm going to turn it over to you. Rohit. Okay. Thank you. Thank you Kelly. Good afternoon everyone.

Thank you for being here. So I'm Rohit Gupta I'm one of the directors at RBC Wealth Management based in the US. I lead the strategy and vision of our advisor desktop, which is on Salesforce, and Business Process Management, which is Pega. Becky, if you want to introduce yourself. Sure. I'm Becky Meisenheimer.

I am technology director for Pega, applications for Wealth Management Canada and Wealth Management US. And I'm joined by a few members of my team here that are ready and able to come up on stage with me if, if I if you guys stumped me in Q&A. Great. Thanks, Becky. All right. So who we are, right? RBC or Royal Bank of Canada? We are the US Wealth Management division.

We're based in Minneapolis or headquartered in Minneapolis. We are the sixth largest full service broker dealer firm in the US. So we have over 2200 advisors spread across 192 branches and in 42 states. Currently, we are at over 650 billion in assets under management. So that's really giving you the scale of of who we are.

So that's our main private client group. We do also have clearing in custody business line which basically uses RBC for clearing and custody. And those are non-captive advisors of ours. All right. So what was our automated or automation vision with Pega and Salesforce? Right. It was really very simple to streamline or create a unified desktop experience for our advisors by enabling them to view an action Pega cases right from within Salesforce.

So very simple vision journey that we had kicked off in, I would say early 2023, to to make this happen. All right. So now why this was needed, right? I think a lot of you probably would be in the same sort of situation or already been through this in the digital era of transformation and with AI. So some of the pain points that we had or heard from our advisors was they used to swivel chair.

They used to service their clients by accessing multiple platforms. I don't think that's that's, uh, you know, I mean, probably pretty sure it's very common in any of you that are in wealth or banking. Uh, but it was one of their pain points that it used to take them longer to service their clients.

So we needed to streamline that experience. We also wanted to use technologies and with Pega, uh, which could help us with faster time to market when it comes to regulatory changes. Now, five years ago, I don't think anyone or, you know, financial advisors would come to RBC US wealth for technology. Well, that's completely changed. In the last five years. We've gone through a significant transformation from our on our tech stack, and it is definitely one of the criteria that now our advisor recruiting team really uses to recruit financial advisors. Also, one of their pain points was reducing clicks and navigation.

So of course our number one expense today in US wealth is advisor pay. So if you make them more efficient reduce clicks for them. Give them the information right where they are. It makes makes it makes them more efficient, helps them grow or drive client relationships and bring in more revenue within the US.

So that was basically what we wanted to do. And surface Pega requests from within Salesforce sort of was one of the financial advisors wish list. All right. So with that, that's where we coined or created a Pega force. It's our branded internally branded feature. Or I would say capability, uh, you know, bringing Pega and Salesforce capabilities together to create.

And the objective was to create that 360 degree view of our clients and customers within Salesforce. Becky, if you want to talk a little bit about the approach that we took. Sure. So we knew our tech stack that we had for our Pega application was not going to meet the needs of Rohit and our business for for the 360 degree view or for any of the other future things we wanted to to endeavor on.

And so what we had to do really is we looked, took a step back, and we looked at our application and we looked at we we decided we needed to modernize Pega. We needed to modernize the application. We needed to stop customizing the application. We were on a legacy application that was highly customized.

We were doing custom APIs that required us to make changes. Like anytime we did a code change, we also had to change the API. We also had to the consumer also had to change their their system as well. And so we knew we had to get rid of all of that duplication. And we needed to start fresh. So we modernized our platform.

We focused on reuse. We focused on out of the box capabilities. We focused on low code. So that could give us the speed to market that we needed and enable us to spend time on critical tasks versus maintenance and dual overhead and all of that. Great. And really the outcome of that, taking that approach was to create this strategic integration between Salesforce and Pega to marry Pega's sort of case management features and capabilities with Salesforce's record handling precision to create that unique Pega force integration to surface Pega requests from within Salesforce.

All right. So let me take you through sort of our journey and timeline. Right. And how we basically went from discovery or inception to all the way into production. So this really kicked off, I would say in late part of 2022. So 2022, I think it was September or October when Pega Process AI extender was officially or made available for use.

So from then we started evaluating, and one of the prerequisites that we got to know is we were actually on a legacy version of Pega. So one of the prerequisites was to modernize that. We had to get on a modern or right now we are on Pega Infinity, and we had to modernize that to be able to leverage these benefits with Pega Process Extender.

Now, of course, you know that that was step one. So March, I think, or or uh, early I would say spring of 2023. We we created this four year plan or four year transformation plan. So 2023 kicked off the modernization efforts, brought in a couple of requests from our legacy version into Infinity. And in parallel, we started the deeper evaluation of Pega Process Extender.

I think anyone that's in regulated industries in this room probably knows going through a SaaS to SaaS integration and getting it reviewed and approved by infosec is itself a year long project, right? So when we kick this off in 2022, 2023, we knew we were we were looking at almost a year after when we would implement it.

And that's just more around nothing from a Pega standpoint or Salesforce. It was just again, every company has their different timelines for infosec reviews and the process that we have to follow. So that's how how much longer it took us. Now in parallel, what we wanted to do is for a time, a faster time to market.

We started hitting the Pega APIs directly using basic Salesforce Lightning Web components. So that was our step one in parallel, as we were awaiting Pega process Extender to be fully approved and used. So and in parallel, we also knew that our advisors use mobile app. So IT or Salesforce mobile apps.

It was important for us to meet them on this experience within that Salesforce mobile app as well. So fast forward that by the year 2024, early is when we had a completely Pega process extended approved, which I think is a very unique integration because now with Pega Process Extender, when you make a change on that on Pega side, you don't have to redevelop that on Salesforce in those lightning Web components.

The package which is unmanaged package automatically handles that with you. So for me, that was a very, uh, you know, creative, unique, uh, integration Experience to not deal with continuous change when something changes on the Pega side. So in 2024, about summertime is when, uh, we, uh, you know, had we provided the ability to view and, uh, you know, cases or Pega requests from within Salesforce, both on desktop and mobile.

Uh, and then, uh, that was sort of year two, year three. What we wanted to do was in 2025 is get them to be able to action on those Pega requests from within Salesforce. When I say action, it's basically getting our supervision, getting our risk teams, getting our, you know, complex management, all those management teams being able to also, uh, you know, be able to use Salesforce and Action, which they all are already on Salesforce, like we have over 5000 employees and 95% of them are actually already on Salesforce for various sort of departments or groups that they use Salesforce for.

So for us to provide this way to action within Salesforce was that step two, which is what last month we we enabled that and we got that working for them. So that's now live for those folks in in production and they actively use that. And the last piece I think, which I'm very passionate about, is now allowing them to create Pega requests from within Salesforce, which will completely eliminate that swivel chair experience.

So that is what we are working on in late 2025 or early 2026 to to enable that so that that and along with, uh, you know, getting some sort of agentic experience in place, which we already have at Salesforce Agent Force and having it or building a multi agent use case or something with API's to have agents or a Salesforce agent talk to a Pega agent, I think is definitely something that we would actively be exploring and considering over the next year or so.

With that, Becky, if you want to add anything in terms of how. Well, one thing I'd like to call out is, you know, this we're focused a lot on reuse. We want reusability, not just within this specific application, but we want reuse across well, we want to be able to use what we build for us in Canada, for wealth Management Canada.

We want to be able to extend that if it makes sense to our enterprise partners that also use use RBC or use Pega. So so that's a key a key thing that we're driving. So we're able to leverage this architecture that we built and partnered with Rohit on for our Canadian wealth application. And that's in process now.

Um, hopefully later this year or early next year will be released. Great. All right. Let's let's take a look at really quick, uh, some high level benefits of the strategic integration. I'm going to talk a little more on the functional or business side. And then I'll let Becky chime in from a technical and operational standpoint.

So for us from a functional and I think I've probably, you know, provided in bits and pieces some of these through the course of this presentation, but it was really around productivity, right? The focus was productivity. The focus was to reduce navigation and clicks. So that was a key differentiator.

Again, save them time so that they can focus on growing client relationships. Providing transparency was the other big benefit right. Not having to swivel chair go across different platforms when they're trying to service their clients, bring those Pega requests and display surface them within Salesforce was a huge benefit.

Being able to faster again, faster execution when it comes to front, middle and back office. And as I previously said, like our, you know, middle office back office is all on Salesforce. And if they are referencing to the exact same data, exact same UI, being able to interact from within Salesforce, that just provides them a faster way to service or back office to service front office.

And finally, is that whole integrated experience from a form factor standpoint to having them, allowing them to use it on mobile, use it on on tablets was was key and providing a contextual view. So what we have also done part of this integration is you can go into that component or that visual that we have in Salesforce and click on the unique Pega request number, and it will launch you straight into the corresponding Pega request.

So we do have single sign on between the platforms enabled. So makes it a lot seamless for them. And they don't have to reserve research for those Pega requests or open another window to to get to it. They can get to those Pega requests right from within Salesforce. Becky, for technical and operational.

Well, really the the key value with the Pega extender for Salesforce is that we build the process. Once we don't build the process and UI and then build some rules and some UI in Salesforce, we're not doing the custom integration we're able to leverage out of the box APIs that and create and enable those processes within Salesforce without all that duplication, without all that overhead and maintenance, and that what that provides us is the ability to focus on innovation, focus on other key strategy items to really drive the business strategy forward.

And that's where the cost avoidance comes in. You know, reuse of the architecture, reuse across our Pega applications is also a key piece of that. And the elimination of the swivel chair that you mentioned. Yeah. And I think I really want to reemphasize some of the benefits that we have listed here, mainly around cost avoidance. So that that's really the beauty about this integration with Pega Process Extender is you change any anything on the Pega side, you don't have to rebuild on the Salesforce side. So that Pega Process Extender is a very unique package built and installable on Salesforce. So provides that provides a way to avoid having to rebuild those integrations and UI within Salesforce.

Becky, how did we do it? So we're using Pega Process Extender for Salesforce, the package that's on the marketplace. And as Rohit mentioned earlier, we enabled so so the user accesses goes to Salesforce. They log in that Salesforce then calls the Pega API. They go through our Apigee gateway for security purposes.

Pega provides them with an access token. And that enables them, Salesforce to make additional calls to the APIs in order to pull back client data and case data from our Pega application. So while this diagram is kind of simple, it, uh, it actually was very, very complicated. As it said, it took us a long time to get through architecture because we're interacting with a Pega on prem cloud platform that's connecting to Salesforce on their public cloud environment.

And that just if you're going to do this, I'd set aside some extra time for the architecture piece. I think that's probably the longest in your journey to get through. Don't want the data or client the client data to get exposed where it shouldn't be so great. And underlying the Pega extender and why using out of the box low code is so critical for this to be successful, is that these APIs all tie in and underlie the the Process Extender framework, and these APIs are out of the box.

If you make a change to a case, the requirements on a case that's automatically updated in the API and that would automatically feed through to Salesforce. It also enables us to to expose our Pega processes, kind of that center out that you'll hear, uh, the Pega folks talk about all the time. So it allows us to enable that for other channels like our client mobile channel, for example, for clients to to do these processes.

So you can see which ones we've already implemented and which ones are are on our future roadmap and create case. That's the next one we're going to tackle. Great. All right Becky, I don't think folks here believe us until we show them. So why don't we show them? And, uh, as I pull up the demo, uh, so none of this is Figma or prototype? I just want to be very clear.

What you see in the next 2 or 3 minutes is all things that we have live in production. Uh, so. No. No. Figma. Welcome to the demo for Pega and Salesforce integration. Royal Bank of Canada wealth management advisors manage client relationships at a household level. Leveraging the Pega extender component in Salesforce enables financial advisors to view and action requests across different platform like Pega in a single location, delivering a unified, streamlined, and consolidated experience.

It also allows the financial advisors to view requests on the go from their mobile devices. Requests initiated in Pega are displayed in Salesforce at a household account and client level. RBC refers to the Pega application as Infinity, the name which you will see being referred throughout the demo. Let's jump right in.

From my launcher in Salesforce access Infinity requests were the Pega requests requiring action are displayed based on user access. Requests appear in the order of date created, with the most recent listed at the top. The columns within Salesforce are sortable by clicking the arrow next to the column header. Clicking the eye to the left of the request provides a custom view of request details. The data displayed is retrieved from Pega. All required documents are specified within the request, and any attached files or documents will be available for reference during the review process. The Approval Highlights section from Pega displays at the bottom of the page to summarize the request.

After reviewing the request, the user can approve the request, reject it, or request additional information from the initiator. If reject is selected, the user will need to provide a reject reason and add applicable notes as to why the request is being rejected. Similarly, a note section will appear if request for additional information is selected.

If approve is selected, the request will continue to the next step in the process flow. If we go back to Infinity and review the case, we can see the request in open approved status and the request is routed for fulfillment. This integration brings us one step closer to completing our automation vision, and in the coming year, we look forward to additional functionality using Pega extender within Salesforce.

All right. So with that, Becky, let's share some lessons learned through this past year with the second phase of our integration. Sure. I want to call out on that that video though, that that we that everything you saw being done in Salesforce was actually being fed to Salesforce from Pega via the API and the process extender.

So Salesforce did not have to build the UI. They did not have to build the rules, any of that. That's all coming coming from from the application. As far as lessons learned for the past year, you know, we did enable mobile. And I want to thank our Pega partners for that on the on the extender and the API teams, because, you know, it was working on the Salesforce desktop, but the mobile application they partnered with us to to get that working.

So now, you know, our advisors can view Pega cases on their mobile device. And we found that some of the features, things that are out of the box in Pega weren't necessarily showing up in the API. And Pega partnered with us on that specific one listed here is for for document attachment. So I guess kind of as a bigger, broader generalization, you know, a key piece to this, all of this is having your business strategy aligned with your technical strategy and having a clear vision of where you want to go and how you want that advisor and client experience to be.

As you've seen, just from the few minutes Rohit's been on stage here, he has that clear vision, which makes it much easier for me and my technical team to know what features that we need to deliver as a group and think about this holistically so that we build it once and and reuse. So, um, I guess that's my biggest thing to you is make sure you have a, have a clear, clear strategy how you want this to look when the advisor goes in and how your process will be accessed, who accesses it, could it be accessed by a client? Could it be accessed by an advisor, someone in the middle office? Um, looking at that and then understanding how you can plug in future capabilities into what you've built.

So you've stayed out of the box of Pega offers. Agentic I work workforce help like you can embed that into your process and, and, uh, easily and quickly and then make it available. Yeah. And I think just to add, Becky, I would say a lot of the success really also goes to our change management folks, like our tech enablers that are out in the field.

They are getting all that feedback, uh, you know, to us from advisors, management, users, the supervision, because it's really for them. And we want to focus on building something that will really that we will have high adoption, and which is one of the reasons why we are sitting at 95, 96% of adoption of our, uh, you know, platform.

So it a huge credit goes out to them as well. And I see a couple of them in the room here. Uh, but none of this would have been possible on the location, the experience without their partnership. So definitely wanted to call that out. And staying out of the box just to to again call out that the change management group, staying out of the box is not always the easy the most preferred route.

Sometimes, you know, the business has their way of doing things they want. They process this the old way. They want to keep it the old way. So really, the having that business technology partnership alignment on how you want to move forward, that we want to keep the upgrades low cost. We want to reduce customization and maintenance, and then being able to make those trade offs together is is an important piece of that.

So yeah, and I would say just on the US side, like compared to last year, uh, you know, the focus was not as much on mobile than, you know, in the last year as it was in the past. So it has been incredible to see how folks actually are more focused towards having features and functionalities be available on the mobile app over desktop, like they are probably, you know, out on the golf course with their advisors or with clients and and meeting them, and they want to provide that update or quick service right there.

Uh, so it's something that I would highly recommend, pay close attention from a form factor standpoint on if you have the same personas and use cases of enabling features on desktop, tablets or mobile because that can get a little tricky from just the real estate standpoint of viewing all this information and being able to action.

Great. With that, that's all we had for you guys today. To give you a sneak peek into what we have done part of our journey, and would like to open the floor for happy to take any any questions if you guys have. And if you do have, please uh, come up to the mic. That'll make it a lot easier for other folks to to also listen to the question.

Yes. Hi. You said you have a front office back office. So if you have users user group that only log in to Salesforce and then you have user group B who only logins to Pega they don't talk to each other. So you create a case here that goes to fulfillment. And now this guy needs some information from you.

So then how do they. So exactly. So this is the perfect use case for that where, say, an advisor goes in and initiates a Pega request from within Salesforce. They don't login into Pega and then a supervision or risk or compliance or whoever is approving or reviewing only in Pega. They will see that back and forth interaction.

So when you request for information from Salesforce, it's displaying in that note section within Pega as well. So they are responding from Pega. And when it comes back then it's making it actionable within Salesforce for the audience that is in Salesforce. Every everything for that workflow. Pega for that case.

So if I use an example, we have a case type that's creating a wire. So everything for that wire case is orchestrated and managed by Pega through the API Salesforce Extender. So any update I do from Salesforce. I'm doing it while it looks like I'm doing it in Salesforce. It's actually connecting to Pega in the back end.

And Pega is telling like rendering on that UI. Okay, what's the next step? What's the next step? And then that goes through. So it's all in Pega and it's all real time. So if I'm a user who has access to Salesforce and a user who has access to workflow, I should be or Pega, I should be able to see the updates real time in either system.

If your user who logins to Salesforce, he has hundreds of thousands of orders or cases in his, so he won't know that the fulfillment case needs some information from me on this order, right? He will log in and maybe he'll work on his top priority list. So so just to answer that. So in Salesforce, what we've done is when something is sent back from Pega.

Right. And the advisor needs to action that little utility bar in the demo at the bottom. That's a Salesforce feature. So we are able to track through push topics, which says that, okay, now you have 2 or 3 things that have come back, and this is sort of your cue to action, and you have various ways within that screen to basically sort the list or look at priorities and basically action.

But it does highlight that little utility bar when something new has been pushed, or there is an information that was requested from within Pega and sent now to the advisor on on Salesforce. Is that an API call? It's through push topics. So it's through Salesforce push topics. So whenever the API's are hitting and we see that okay, you now have five say Infinity request waiting for your action.

It immediately lights up. So we're using behind the scenes. We're using Push Topics framework of Salesforce to light that utility bar. Okay. Thank you. That's right. We have the same setup. Okay. Awesome. I have a question. Two weeks ago we implemented the same symptom connectivity between Pega and Salesforce, but through the API custom API.

What is the advantage Pega Infinity versus what we did? So go ahead. Um, I guess it depends on what you mean by custom custom API. Did you use basically I'm assuming like lightning web components or or something. You created the UI yourself in Salesforce? No, we have a UI, we created UI and Pega OK.

We have a data from Salesforce which we need to bring to to the Pega. OK. We just getting data out? Yeah. Send it to Pega updating and send it back. That's what we did. Okay I see you're using different approach here. Yes. So this is the Pega process extender package. So the real benefit of that is it comes with the UI.

So your use case is probably the reverse where you're sending information from Salesforce to Pega right to Pega, which. Is. Yeah, if you send it back to then you're basically using the APIs and the component, the Pega process extender. You don't have to build that in Salesforce. No, no. We create a callback API and just sending them back.

Which I think you can, I mean, through APIs for our use case was rendering the UI of Pega in Salesforce. We are not sending any assets information from Salesforce back to Pega. So for us to avoid the duplication of building lightning Web components and creating the UI that you saw, it wouldn't have made a lot of sense.

So that's why the Pega Process Extender allows for that. In your case, the data will stay in one place. Yes. Rather than duplicated. Correct? Yes. So none of the data in Pega is actually being updated in Salesforce. It's all just through, uh, like, you know, almost sort of a iframe, but it's not really an iframe.

It's happening through your integration. Yes. Correct. Okay. Thank you. I want to I want to maybe ask a clarifying question around what he was saying, and hopefully I'll understand it a little bit better, if I understand correctly. DX API you're actually exposing a fulsome process in through this lightning connector.

So when you are starting a process, you can have multiple steps and it's a single interaction. Whereas if you're going to create a custom API and you want to have a multi-step process, you're going to have to create multiple custom APIs. So I think if you get the lightning extender working, you can use it again and again and again for whatever process.

And each one is like one interaction, rather than building a whole library of APIs and then having to know how to stitch them together into a process. Yeah, I think it depends on just the use case and how the data strategy and data sharing is happening between platforms for us, because Salesforce is our integrated advisor desktop, that's where our advisors are spending the most of the time.

So we want to surface or render information from other platforms in Salesforce. But yes, to your point, if you have a data is moving from Salesforce to Pega, then you probably would be better off using APIs. But again, I think to your point, if you are bringing a whole process in Salesforce, it's best to use the lightning or the process extender.

Correct? Yeah, and we have similar use cases for other platforms where we basically use MuleSoft to route any data. Movement in and out of Salesforce is happening through MuleSoft for us. So when we have other platforms onboarding and and reporting that is accessing our data through APIs. So that's when that comes in.

But in this case, when we are rendering a whole process, it made it a lot seamless. Correct. Exactly. Yeah. Yes. Thanks for the presentation. Like, you know, we were exploring the similar, you know, web extender for our bank. So what we have been told is like, you know, there are ready made components available for Getnext create case.

Workplace work basket. Like, you know, just do like, you know, prescribed steps in Pega and as well as in Salesforce, you get the widget. In Salesforce, you just have to drop it knowing your roadmap. I mean, I saw like a very big roadmap. What kind of like where was the bottleneck? Was it a Pega of the problem or the the actual extender? Was the was the challenge? Uh, you mean before we could implement it? Yeah.

I mean. During this journey. Right? Yeah. I mean, the biggest, the biggest challenge initially was the getting the architecture approved. Like, that took us a really long time because of the SaaS. And then on prem I don't. Yeah. And I think just to add, I would say like the whole authorization mechanism was very different because again, when this was rolled out in 2022, we all were just learning about how Pega Process Extender actually works, how the handshake between Salesforce and Pega is happening.

We partnered very closely with the Pega product teams to basically see how this architecture pattern of SaaS to SaaS could be approved. And now if you see like three years down, down from where we were, this is very seamless. The exact same components that you're talking that's part of the package. So that's the Pega process package that we have installed in Salesforce.

And we are dragging and dropping get cases. We are dragging and dropping managed requests in Salesforce Lightning Record pages to basically enable that. So it's all configured behind the scenes from an authorization or OAuth 2.0 is what we use for that handshake to happen. And then after that, as long as the downstream APIs, which are fetch or APIs, is pulling the data from, as long as those are modernized and you have the necessary environment that it can be compatible with, you are just simply dragging and dropping.

Now, in our case, I will say that we because it's an unmanaged package sales, you can make modifications to it. So there are two versions of how. The payloads. Sorry. The the packages. You guys customized. It? Yeah. So on the Salesforce side, the DCS APIs all remain as is. But on the Salesforce side, our advisors wanted a way to download them to a spreadsheet.

So the table or the table that you saw that's not natively available, part of that display request component from Pega. But because it's an unmanaged package, Salesforce, you can go in, you access the source code and you can actually add code, you can remove code or whatever. Now the technical debt to doing that is if Pega now makes a modification, you'll have to retrofit those changes into that, uh, you know, version.

But that's something we closely work with Pega product team that are owning this process extender package. And basically we're saying that these are the features that our advisors are requesting. And if it's on the roadmap, we would typically tend and avoid to make those customizations. But if it's not in the 12 to 15 month sort of roadmap to enhance that package, then for now, we would go ahead and add those delta components ourselves.

And we're modernizing. The other part of this journey that you don't see on here is we're also shifting processes, kind of one by one, from our old application to our new application so that they can leverage the process extender. So so that's the other part of this journey is, is we're rebuilding and reimagining those, those processes so that and then each time one of those processes is added it automatically is is reflecting in in Salesforce.

So yeah. Great. Great question. Anyone else. Becky and Rohit thanks for sharing your experiences. Um, one question kind of related to what gentleman was asking. Um, I know most of the heavy lifting is done on the Pega side, right, for this whole integration to work. So in your experience, um, I just want, like an honest opinion.

Like how much out of box works on the Salesforce, right? Like, um, how much work you did on Salesforce and how much most of the work I know is on the Pega side, but out of box. How true is that? Yeah, no, I would say I think it's 80% out of the box. 20% is because we were picky about certain aspects of it.

So I think two features that I can recall, one I just mentioned around, uh, being able to download as a spreadsheet. Again, our advisors love that for whatever reason. So that's one thing that we had to customize in that component. And the second one is the contextual launch. So there is a column that you probably might have seen or missed.

The very first column is that unique Infinity case number. It's actually an hyperlink. So we created that. So link there. And so if you click on that it's just basically redirecting that to opening the corresponding case. So those are really the two customizations I think that we've done on the Salesforce side to support.

Just another easier way to navigate between the platforms. I don't know, Becky, if you remember, if there was anything else that we did specifically. On the Pega side, we had to look at the design of the processes and just make sure that they're working with DX API and test that it's rendering properly. So there were a few examples. I think I mentioned one in the presentation where we did have to go back and look at our design and see what if there are workarounds or some way to make it still work the way we want it to work with, uh, with using all of the out of the box features. And you guys are on the latest Pega.

We're on 24. Is that one? Yeah. 24.1. Yeah. And one. One last question how seamlessly the two way communication works between Pega and Salesforce. I had like part of it. But I just want to know like if you make some changes on Salesforce. Not within that, um, that window. But if let's say you have some related data you're showing on a different part of the screen, right? You make changes over there and then you want to see kind of it goes to the same database and you want to see that reflected on the Pega.

So and in the reverse direction. Yeah I think ours is very I would say very straightforward in that aspect because we don't pull in a lot of Salesforce information in Pega. It's really, uh, you know, accessing Pega information right within that component or within that UI of Salesforce. So anything that you're changing there is directly integrated to Pega.

So as you change real time, it reflects within. Uh Pega. I think definitely, you know, everyone will have different use cases of how they are exchanging data, but for us it's real time. It's not even I would say near real time. It's happening immediately. Yeah. Yeah. But how about if I change? A I make a change in Pega.

Right. Let's say somebody opened the same case in Pega and they are making the change over there. I'll introduce you to Naveen, my dev manager. The brains behind this. What? We are still thinking the traditional integration. Right? Where we take the operators or we move the data. This is actually. We have brought the application.

You can't hear. Oh. So the. Idea is, if you look at the traditional integration, either we have taken the users to another application or we have taken the data to another application. But with this, we are leaving the user wherever it is and based on the workflow or based on the action, we are bringing the operator itself, whether it's a supervisor or approver reviewer, whoever is the actor in a workflow, we are bringing him into Salesforce and when he is on that widget, whether it is get assignments or assignments related cases is now actually on Pega is no more in Salesforce.

After the initial authentication, all the UI is the apex UI, but the control and function is Pega, so there is no data movement. Once you have started an action right, there is no data moving between two systems. True for. Both. Yeah. True for both actually. Okay. Thanks, Naveen. Hello. Um, I'm sure it wasn't taken lightly to integrate Pega into Salesforce.

And it sounds like the use case is mostly around, like, service requests of type money. Well, we have money movement transactions primarily. Yes. Okay. So I'm curious if you can talk us through the business constraints that led to using Pega as that resource instead of Salesforce's native service request concept? So I think, I mean, just from a business standpoint, even before we had Salesforce, We already had Pega.

We were on the legacy version. We had integrations to our books and record system with Broadridge and others. So those integrations already existed. So when our focus in 2020, when we kicked off our Wealthtech transformation or tech stack transformation was really to focus on Salesforce for its CRM capabilities, we knew that it's more than that.

It's a platform. So we've evolved that over the last five years. But then also we didn't want to be single threaded just with Salesforce. Salesforce has workflow management capabilities. It has gotten better with flows and MuleSoft and all of that. But Pega also, you know, shines really well when it comes to complex workflow management.

And that's what we wanted to decouple. And when we saw this in 2022 with what Pega Process Extender can do, that's one thing that we are looking at. Any of our vendors that we partner with is are they planning to have a strategic or like a package integration with Salesforce. And we saw this coming with 2022.

And that's when we were like, let's, let's move the complex processes to be kept in Pega, let's modernize Pega and then have it surface. Because really, at the end of the day, to our advisors that are familiar and using Salesforce for them, it doesn't matter how the back end is getting processed. So for us, it was a nice way to decouple both the platforms and have them use for what they are really good at.

Basically, you're basically leaning into the Pega side for the decision management and then the Salesforce just for the visualization. Exactly, yes. And I mean, Pega is one example. We have similar integrations with other platforms. That's why we have we call it our integrated desktop. But yeah, if you want to add anything.

Now it's just really we looked at home of Best Fit. So like Rohit said, if it's complex processes where it's a lot of orchestration, a lot of integrations, a lot of data, like we're we're lean toward Pega for that. And and then you know, Salesforce. We did move some simpler process flows that go from the front office to just to the back office to Salesforce.

Those were built there. That just made more sense. Like basic inquiry of certain things between our front office and ops. We're like, that's not complex. They're just asking a question about something or they're reaching out to middle office from a product question standpoint. So those were all things that folks used to use mailboxes to basically monitor.

So we moved those processes into Salesforce cases. There was not a reason to use Pega cases for that. But for a lot of that complex routing, we do have money movement being one of them in Pega. Thank you. Sorry about that. So earlier, I think we talked about, um, you know, this is a one way connector in that you are embedding the Pega experience in Salesforce.

The user is actually using Pega, but in a seamless fashion as far as they're concerned. The agent is using Salesforce in the back office. Are you now in a situation where you've got users on Pega and on Salesforce? And is there a future of having almost like a two way lightning connector where you can embed Salesforce in a unified desktop on Pega in operations? Is that a vision that you have, or is it is it always going to be two or.

Yeah. So I think just from an RBC US standpoint, I think for us it's always Salesforce at the center of that experience. And because we are on a single org strategy, it's where whether it's front office, middle office or back office are all accessing different platforms and the data from Salesforce.

But I think to your point, I'm pretty sure there will be other companies and other use cases that would want to surface it the other way. For us, it is that single pulling Pega request, showing them in Salesforce, pulling in ServiceNow requests, showing them in Salesforce, pulling in other platform requests and showing it in Salesforce.

So if you're doing a process directly from Salesforce is in channel, you're just going to go ahead and do it. Correct. Is that a straight through process, or do you sometimes send requests back to ops as well? So I think that there are both. It's a mixed use case. Some are just straight through processing.

Some are where ops is still going into those blue screens, green screens, black screens, what are you going to call them and actually doing it. But that's again just technical limitations that some of those APIs are those legacy phase, phase four APIs or, you know, which which just don't support a SaaS integration.

That's one of the reasons. But as we modernize tax, it is making it a lot easier to avoid that experience for back office as well. I think one of our long term roadmaps is definitely to make sure that not only front office experience, but also improving the experience from a back office standpoint to limit the manual navigation that they are having to do.

That's a big topic of conversation for on the Canadian side right now, is do Do they want to have operations users in Salesforce like the model they've done in us, or do you want some other type of integration between the two so that ops doesn't have another app that they have to use? So it's. Great.

I know we are over time. Thank you everyone. I have one quick question. We've been in Agentic AI world all this past couple of days. You mentioned Agentic AI or agents between Salesforce and Pega and sort of some future thinking there. Could you expand just for a minute on that? Yeah, absolutely. No, I think I think it's the step one that we have taken where we have enabled Salesforce Agent Force, and we are now looking, actively looking or exploring at multi-agent use cases.

And I think one of the first one that came up was, how can we bring that data of that Pega has or houses with, uh, you know, Infinity request to be accessed from Agent Force. Right. If you're asking it about a client or a household, if you're asking it, give me the most recent Infinity requests that were created through that Agentic experience in Salesforce.

It should be able to go and, you know, talk to a Pega agent in the back end and bring that sort of experience and provide that response back. So it's definitely something I know that we are actively exploring or working with. Pega. I know there are a couple of prerequisites to it before we could do explore those use cases.

It definitely also would involve making sure the authorization protocol between the agent and Salesforce and the agent, and Pega is accessing the data that they have entitlements for. So I think it's definitely something future thinking for us. But we since now we've been successful with a single agent experience in Salesforce.

We want to expand that to explore other other multi agent use cases. Thank you everyone. Appreciate you..