Modifying the existing Administrator ID

Our Application id built on PRPC6.3 SP1 and CPM Framework.

The Organisation instance name of our Application is GMAC.

So, when the application was built, the Administrator ID was created as Administrator@GMAC. We now want to change the ID to F_Administrator@XYZ. Appreciate if you someone could please provide let me know

  • the impact of changing the Administrator ID
  • All the required codes (which are part of PEGA Product) where we have to make the changes. We know some of the impacted rules are in PEGA-Rules RSV. 
  • Complexity of changing all the required PEGA Product Code, so that the flow error handling logic or any other impacted areas are not broken. 


**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

November 23, 2016 - 1:36am


You can save as the existing operator ID to new Operator ID and refer the same access group. One place you have to be careful when this Operator ID name is hard coded in your application rules.

Others can share their views.

November 23, 2016 - 7:32am


You can save as the operator id and use it for further developement however renaming is not possible. So you cant change the operator id Administrator@GMAC to F_Administrator@XYZ.

So it will be a kind of decommissioning users and introudcing new users . And as Ganga said , one place you have to be careful is the one where you have made references to this user id 

Possible areas include :

1. Routers in flow where you might have used toWorklist and used this operator id

2. Email listener where you are using this operator id 

3. Any delegation  etc.

November 27, 2016 - 6:52pm
Response to Santanu

Hi Santanu,

Thanks for your response. I understand the suggestions given by you and Ganga. But PEGA recommendes to have Administartor ID as Administrator@Organization, as there are some routing scenario(in PEGA code).

So, i was looking for impact and effort in modifing the Pega Provided codes.



November 28, 2016 - 6:14am

Well the routing mostly comes into picture when you face some sort of exception. For example, you wanted to send a mail from your case but it got failed, so system will report it back to administrator . Or for example your flow got stuck somewhere, so system will report it back to administrator and also assign the case to administrator for fixing it. ( problem flow )


So , I guess these are the possible places where administrator@organization will come into picture. However, these areas can be customized and you can put your own error handling logic in order to route them to some other sys admin.


November 30, 2016 - 10:14am
Response to Santanu

Thanks Santanu for the suggestion.