Consider using custom authentication (like SSO) to grant access to a set of users to multiple Pega applications. 

As you know already, the pr_operators table just holds the operator details, but accessing another platform depends on the access group/application/portal mappings, just having a shared table won't work. There are also other dependent tables for operator preferences, skills, workgroups. In any case, I don't think it's a safe approach, but you can still look forward to hearing other opinions if anybody has tried.

Harish,

The goal is not to access the other platform, but just to be aware of the available operator IDs (from the other platform) and their availability, whether they are active etc to facilitate assigning work.

We are already aware of 1 option (synchronizing operators from the other platform) to track availability, however operator signons/activity have to be then captured/cascaded through some API Call. Just wanted to check and confirm if a foreign table option was ever used by any customers for a similar use case.

Thanks

Sethu

Sethu,

I got your use-case now.  As the goal is just to be aware of available OperatorID's from other platforms, pr_operators table should be sufficient. Each instance contains the operator details (columns) along with the pylastsignon(column), availability(blob), skills(blob) and workgroup (column) & workbasket(blob) mapping information.