Question
Capgemini
US
Last activity: 30 Nov 2016 10:14 EST
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.
PEG
IN
Hi,
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.
Pegasystems Inc.
IN
Hi
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.
Capgemini
US
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.
Pegasystems Inc.
IN
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.