Genesys Cloud - Developer Community!

Β View Only

Sign Up

  • 1.  WhatsApp identification and external transfers

    Posted 2 days ago

    We have extensive WhatsApp self service and outbound orchestration.
    We are considering WhatsApp inbound calls through normal IVR.


    Two matters:
    a)First issue is to identify WA calls. How have any of you solved this?
    b)We need to prevent transfers to PSTN numbers due to VOIP legislation.
    In our mind the same agents needs to handle normal voice and WhatsApp calls.
    At the moment we transfer directly to external parties in the IVR and agents can transfer externally.
    We are aware of trunk/site/number rulebooks but has consequences.
    We are not aware of any elegant way to handle this, unless we revert to triggers/api etc.
    Any recommendations?


    #Integrations
    #Uncategorized

    ------------------------------
    Japie Teunissen
    Partner
    ------------------------------


  • 2.  RE: WhatsApp identification and external transfers

    Posted 15 hours ago

    Hi Japie,

    Great questions - both are very common when combining WhatsApp and voice in the same routing model πŸ‘

    βœ… a) Identifying WhatsApp "voice" vs regular PSTN calls

    In Genesys Cloud, the cleanest way is to rely on conversation attributes at the Architect / routing level:

    • Check Conversation > Media Type and channel context
    • For WhatsApp voice (via Cloud Voice / BYOC CC scenarios), also inspect:
      • Direction
      • ANI / Address format
      • External Tagging / Attributes (if you're injecting metadata upstream)

    πŸ‘‰ A practical approach:

    • Set a custom participant attribute in Architect at entry (e.g. channel=whatsapp_voice)
    • Use that attribute throughout routing, scripting, and transfer decisions

    This gives you a deterministic way to separate logic without depending only on trunks.

    βœ… b) Preventing PSTN transfers (while keeping same agents)

    You're right - trunk/site/number plans can solve this, but they impact everything and aren't always elegant.

    Here are better scoped options:

    1. Control at Architect (recommended)

    • Before any transfer action:
      • Check your channel attribute (e.g. whatsapp_voice)
      • Block or reroute external transfers conditionally

    Example logic:

    IF channel == "whatsapp_voice"
   β†’ route to internal queue / flow only
ELSE
   β†’ allow external transfer

    2. Agent-level control via Scripts / UI policy

    • Use Agent Script + Data Actions
    • Hide or disable external transfer options dynamically based on channel

    πŸ‘‰ This avoids backend restrictions and gives more flexibility.

    3. Use Division / Queue-based segmentation

    • Same agents, but:
      • Separate queues for WhatsApp vs Voice
    • Apply:
      • Different transfer permissions
      • Different flow logic

    4. Last resort: API / Trigger enforcement

    If you need hard governance:

    • Use Triggers (conversation or transfer events)
    • Detect invalid transfers and:
      • block
      • reroute
      • log

    🧠 Recommendation

    Best balance between control and simplicity:

    βœ… Use Architect + attributes for channel identification
    βœ… Enforce transfer rules at flow level (not trunk level)
    βœ… Optionally complement with Agent Scripts for UX control

    This avoids global telephony side effects while keeping agents unified.



    ------------------------------
    Cesar Padilla
    INDRA COLOMBIA
    ------------------------------



Related Content