if the structure is logically different ,you can try with federated case management concept.

A Service Package is associated to one Access Group, hence can only perform tasks allowed by the Access Group's Application.

An Agents rule is associated to a ruleset. The same ruleset can be added to every Application that performs Business Logic processing. Let's name this ruleset "OperatorChangeHandling".

The create/update/inactivate-an-operator-record Service's Application should not perform Business Logic processing, hence would not include the above-mentioned OperatorChangeHandling ruleset.

Instead that Service should create/update/inactivate the indicated operator record as instructed then create a Data-Operator-Change record stating what action was performed on what Operator record.

An Agents rules defined in the OperatorChangeHandling ruleset would periodically check for newly added Data-Operator-Change records. The Activity that the OperatorChangeHandling Agent calls would implement the Template Pattern. Each Application would override the allowed extensions points according its specific requirements. 

All code common to operator change handling would be included in the OperatorChangeHandling ruleset. Ideally the OperatorChangeHandling ruleset would be included in a Component.

An alternative exists to having each application poll a queue populated by a Service. A more efficient implementation is having the Service "impersonate" an application temporarily and safely within a Template Pattern-permitted override.

The Access Group of the PegaUnit Service Package is PRPC:Administrators yet that Service is able to switch access groups as-needed to execute test cases and suites.  java step 15 in the Code-Pega-List pzValidateInputs Activity is shown below.  Note how the current pxThread's  Access Group is can be changed to the AG specified by an "AccessGroup" parameter.

String targetAG = tools.getParamValue("AccessGroup");
String strAccessGroup = tools.findPage("pxThread").getString(".pxCurrentAccessGroup");

com.pega.pegarules.priv.authorization.PegaAuthorization auth = (com.pega.pegarules.priv.authorization.PegaAuthorization) tools.getAuthorizationHandle();        

try {
   PRThread prtRef = tools.getThread().getRequestor().getThread("STANDARD");
   ((com.pega.pegarules.priv.authorization.PegaAuthorization)prtRef.getAuthorization()).setActiveAccessGroup(prtRef, targetAG,true);
} 
  catch(Exception ex){
    oLog.error("Unable to switch to user provided access group'" + targetAG + "'.Following exception is encountered:" + ex.getMessage());
  }

Hi,

Can you please elaborate on your application structure a bit? Is it as follows:

AppA built on AppBase

AppB built on AppBase

AppC built on AppBase?

You can do a content search for "setActiveAccessGroup​".  This function is conditionally called in the System-Queue-ServiceLevel agent's EstablishContent activity. 

The only example that comes close to being a "pattern" AFAIK is what occurs in pzGetTestsAndExecute​ but exactly what each Application overrides is not clear.  Any Application can define Test Cases; pzGetTestsAndExecute can execute any test case given its pxInsName and Access Group.

If you are running 7.2.2 or greater you can develop an application that the service calls and that every other application adds as a built-on application. The other applications would override a stubbed-out / templated rule to implement their specific Business Logic.

An example of the above app structure, minus any template rule to override, is the Deployment Manager application that you can download from Pega Exchange. The "DevOps Orchestration" Manager application is built on an application named "PegaDevOpsFoundation" which "Candidate" applications are required to be built on as well.

See: https://community.pega.com/knowledgebase/articles/installing-and-configuring-deployment-manager-32x