Good afternoon. I am currently leading the change management for our new Genesys Cloud rollout and I’m trying to automate our post-call feedback process. I’ve set up a Data Action in Architect that calls our third-party SMS gateway to send a survey link as soon as a call ends. However, the Data Action consistently fails if the customer’s ANI is in the standard E.164 format (e.g., +1555…). The SMS gateway requires the number without the leading plus sign. I’ve provided a detailed breakdown of the error logs below. Is there a simple way in the Data Action configuration to strip the plus sign from the variable before it’s sent in the JSON body, or do I need to involve our developers for this?
Hello. From my perspective as a GDPR specialist in Germany, I recommend being very careful with how you handle and modify customer phone numbers during these outbound automations. To solve your technical issue, you can utilize a ‘Velocity Macro’ within the Data Action’s ‘Request Template’. You can use the $input.phone.substring(1) method to skip the first character (the plus sign) during the JSON serialization. It is a very clean methodology that keeps the logic within the Data Action itself, ensuring that the sensitive PII is only modified at the moment of transmission and not permanently changed in the platform’s core data.
I have been trying to document this exact scenario for our new admin class! It is so incredibly frustrated that the Data Action engine doesn’t have a simple ‘Phone Number Formatter’ block! Using the Velocity Macro that was just mentioned is the correct technical way, but it is a total nightmare to explain to non-technical admins! If you don’t want to mess with the code, you can also use a ‘Decision’ block in Architect with a Right(Task.CustomerAni, Length(Task.CustomerAni) - 1) expression before calling the Data Action. It’s much easier for trainers like me to visualize, even if it’s slightly less efficient!
I’m building a custom agent desktop and we handle these phone number formatting issues constantly. While the Architect Right() function works, it will break if the number doesn’t have a plus sign (which happens with some internal transfers). A more robust developer approach is to use the Replace(Task.CustomerAni, '+', '') function. It’s safer because it only removes the plus if it actually exists. Also, ensure your Data Action is set to ‘Suppress Nulls’ in the response, otherwise your SMS gateway might reject the whole payload if one of the other optional fields is empty. It’s a small detail that saves a lot of debugging time!