Hello, 

Today we integrate with Genesys PSDK, and retrieve agent-to-queue associations from Genesys for our business logic. We do the following to build these associations:

1. For each agent, we look at the agent groups that they are members of
2. Then, for each of these agent groups, we check their Origination DNs to see which queues they are associated to (Home -> Agent Groups ->Origination DNs)
3. Finally, if we are using DN groups, we look at the DN groups and check the DNs that are in each group.
4. With this information, we form associations as agent ↔︎ agent group ↔︎ queue ↔︎ DN group (if applicable)

We have a question if the customer doesn't have Origination DNs added to Agent Groups, how can we understand which queue / DN Group the user will be routed calls from? Is there an alternative way to retrieve the agent-to-queue associations from Genesys?

Also, today, if the Origination DN for the agent group is not present, we get 0-value statistics for queues (Number of Agents Ready, Number of Agents Not Ready, etc.). Does Genesys allow not having Origination DNs associated with Agent Groups but still calculates queue metrics? How standard this setup is in Genesys?

Guessing it is about Virtual Queues.
Association agent - Virtual Queue either is statically configured (through Origination DN as described above) or also can be obtained from "real life" (which targets (agent groups, skill expressions) were used when routing calls from one or another Virtual queue).

Statserver requires static configuration (otherwise when calculation statistics for virtual queues it will consider them as empty).
So using Origination DNs (where only possible) is almost mandatory in such cases.

"Real life" information about queues and agents can, basically, be obtained from URS (not sure though if using PSDK is applicable here).
Meaning that URS knows (from running strategies) which virtual queues were used and which targets were used for every such queue, etc. and has sort of internal mapping agent - Virtual queue. It provides REST API to access some of this information (including statistics for virtual queues like number of available agents, etc).
While no origination DNs are required in this case, should be noticed that URS knowledge is based on content of strategies it run and accordingly URS must run at least once some strategy (which uses the virtual queue) before it can provide meaningful data about this virtual queue