Good solution, thanks for sharing.

Not that I know of. Would an option be to name the campaigns in a way that you can tell which are which?

I don't have an answer but thought I'd complicate your use case a little.
Depending on the version of POM, a supervisor has the ability to change the pacing type during the running of the campaign, meaning that whatever the strategy says may not be the actual pacing that was used over time. Just something else to consider. Have you thought about subscribing to Kafka events to gather the type of information you are looking for?

Raja, When you say Excel Spreadsheet, I'll assume you mean a .csv file. To import a file from your local PC, you'll need to click on the Upload Contact button on the Contact List page, then browse to the file on your PC. If you are looking to upload contacts from a Windows Share, you will need to a NFS/CIFS type of share (with the correct ownership/permissions) that you create on the EPMS Linux Server.

The Avaya Developers Guide says from POM 3.1 and later, only the REST web services will be supported for existing and new POM functionalities.

There is an Avaya KB related to the Rest WS where v2 produced this error but changing it to v3 had success.

Let's assume you are using the pauseAssociatedCampaigns optional parameter set to true.
The POM Developers Guides provide the following description:
If pauseAssociatedCampaigns is set to “true”, all the running campaigns associated with the contact list will be paused, contact list will be emptied and the paused campaigns will be resumed again.
Note: Use this option with caution. It is recommended that the use of this option should be prohibited when dialing is in progress. If the campaign jobs fail to pause within a stipulated timeout interval, then they might remain in PAUSING/PAUSED state until they are manually resumed.

Although this is an older post, I wanted to provide some feedback.
There is now a WS that can empty the contact list. Another WS option is to exclude (Mark Uncallable) contacts and then empty the list at a later time. Marking Uncallable can be done on an individual basis or by importing a list of contacts that you want excluded.

We don't usually implement Zones so I can't offer great first hand advice but the Avaya POM User Guide does mention POM Zone usage with some different examples starting on page 491. https://downloads.avaya.com/css/P8/documents/101077333 Additional information related to Zones are provided in the AEP Admin Guide.

Francis,
The behavior you describe indicates they may have "Background AMD" turned ON in the Call Node of the Campaign Strategy. There is also an "Action on AMD" setting that seems to be set to "Disconnect the call". My suggestion would be to turn OFF Background AMD in the strategy to see if it resolves the issue.
Here are some details of the feature:
You can specify the call classification that is done on the customer call after being patched with the Agent. Background AMD is applicable only when the Enhanced CCA option is set to “ON” and the Call pacing type is either Cruise Control, or Expert Call Ratio, or Progressive. Background AMD is set to of “OFF” by default.

If Background AMD is set to “ON”, then you must select one of the following values from Action on AMD:
Disconnect the call
Leave a Voice Mail
Continue with Agent

Use Action on AMD to specify what action the system must take if the call is classified as Answer Machine.
If the Action on AMD is set to Disconnect the call, then the Result node for Answer Machine allows only Retry operation. Retry is an optional operation.
If the Action on AMD is set to Leave a Voice Mail, then the Result node for Answer Machine allows only Application operation so that the system can leave a message for the customer.
If the Action on AMD is set to Continue with Agent, then the Result node for Answer Machine allows only Agent operation so that the agent can decide next action.

See Avaya PSN005663u for more details.

Problem description
The readme file for POM Event SDK mentions that Event SDK package includes the file “avaya-pim-eventAPI.jar”.
However, this file is missing from the package in POM 3.1.2 and higher releases.

Workaround or alternative remediation
The file “avaya-pim-eventAPI.jar” is also available on any POM server in the $POM_HOME/lib/common directory. Anyone who needs the file can access it on a POM server of the required version.
Steps to copy the avaya-pim-eventAPI.jar file:
o Download and unzip the POM Event SDK package on the target system.
o On unzipping the package, several directories get created as described in the Event SDK Readme file. One of these directories is “libs”.
o Copy the avaya-pim-eventAPI.jar file from the $POM_HOME/lib/common directory on the POM server to the libs directory on the target system.
o The Event SDK package is now ready to be used.

I'm not the Certificate expert, but your list looks OK to me.

Check out this Avaya KB, it has some info on the 9012 error
https://support.avaya.com/ext/index?page=content&id=SOLN315394

You mentioned that the POM services are all up.
I'll assume you've had success running a test agentless campaign. It's best to use the AvayaPOMAnnouncement application in your test campaign since that will verify that your OD license is accessible by the app server (as well as verifying all the certs).

Here are a few things to consider

Common error/notification on agent desktop for error 9012 : Agent manager is not initialized properly. Common reason for this is that certificates on server side are not exchanged properly. Check the Appserver keystore as well as the server.xml file on the appserver.

Remember that a password is required to be set on the Agent login (not a security code)

The Agent Web API Service Licenses are required for the POMAgentSDK service. This SDK is available only for Workspace Elite Integration. POM agent SDK microservice acts as proxy between Web desktop (workspace) and Agent manager service.

I'll assume you are using Workspaces for Elite since you mention cards. It's sounding more like a Workspaces issue . The POM Agent API guide talks about "ownership" of the contact and that seems to be some of the issues you are describing. Since you are able to do external transfers OK, I don't think it's a SIP issue (but may want someone to do a tracesm during the interaction just to check). There isn't a setting in the strategy that controls the transfer/conference ability. I will point out that I've usually noticed that the agents should both be in the same campaign AND in the same call node for the conference to work with success.

I've found that a "network refusal" is usually more of a call routing issue. You may need to have the agent prefix an external transfer with a 9 or 91 or just a 1. If transferring to a VDN or an internal ext, just need to make sure that the SIP trunks can route that call. It wouldn't hurt to verify the Invite/Replace to make sure an agent can drop off the conference call and that the called party and the transfer party can be properly merged afterwards and continue talking.