Thanks ! You have just demonstrated why the Service pack should be associated with the implementation and not the FW  layer.The appropriatte solution is one Service pack per implementation with independant Access Groups for each.

Hi,

 Very First, I would like to say thanks for your valuable time to guide us and clarifying all our doubts in LSA. I seen some couple of post Email Work Processig topic in same forum.  You adviced us better keep Service Pack in FW layer. When create AG  fro Service Pack, my understanding is, it should be ApplnNameFW:Administrator more generally right ?

Please refer the post : 

<< https://collaborate.pega.com/discussion/email-processing;  (Sorry for duplicated this post. 

Yes, I agreed in my post you answered that there should be specifi implementation Service Pack. But Again can you please confirm below is design for yours reply

<<

The appropriatte solution is one Service pack per implementation with independant Access Groups for each.

>>

If I have Org-IN-SampleApplnIN-Work , Org-US-SampleApplnUS-Work, Org-FW-SampleApplnFW-Work.

Let say I have two difference Email Creation work for each implementation layer. In this case, I have to create three AGs. 1. SampleApplnIN:Admin  2.SampleApplnUS:Admin 3. SampleApplnFW:Admin. I assigned these AG group correponding service pack created in applications SampleApplnIN, SampleApplnUS and SampleApplnFW likewise.

Thanks

Alagar

The best practice is to associate it with the implementation layer. If you carefully read the discussion you referred to above (posted by my co-worker), he advised the same but then he also stated it was possible (although not best practice) to put it in the framework layer with the some additional configuration.

The statement you made at the end is not quite corrrect since there is no need to create the FW layer AG specifically for Email listener.  You would create 2 AG's, one for each implementation layer. Both AG's would allow access to their respective implementation rules and the FW layer. You could create one for the FW layer and an associated listener, etc. for testing purposes, however this would serve no purpose in production as only implementation layer cases are created in production.