Please share any images or screenshots, if relevant.
[Please insert images here, otherwise delete this section]
Please share any other relevant files that may be required (for example, logs).
[Please insert files here, otherwise delete this section]
Share all details about your problem, including any error messages you may have received.
Remove the send from phone number in the OTP Twilio configuration - currently this is causing all messages to be sent from the US number which are being rejected in certain countries. If left blank, this should let Twilio decide where to send from.
In IIQ 8.3, the From phone number in the Twilio OTP configuration is usually treated as a configured sender value, so leaving it blank does not necessarily mean IdentityIQ will automatically defer sender selection to Twilio. Based on the post, the problem is that a US sender is being used for all messages, which can definitely cause delivery failures in countries that require a local sender or a country-specific approved origination setup.
From an implementation perspective, I would validate two things first:
whether IIQ even allows the field to be blank at runtime without validation or fallback behavior
whether the outbound request to Twilio actually omits the From value, instead of just passing an empty value
If IIQ always expects a fixed sender, then this is probably less of a “config toggle” and more of an integration/design limitation for international SMS delivery. In that case, the better path is usually to use a Twilio Messaging Service or introduce a small customization layer that selects the right sender based on the destination country.
So my recommendation would be:
Test blank From in a lower environment.
Check the actual Twilio request payload.
Confirm Twilio country support and sender requirements for the destinations that are failing.
If a single US number is hardcoded by design, treat this as a customization/enhancement rather than expecting native country-aware routing from IIQ.
@r2rd Are you sharing the information or facing some issues? If its later, please provide more details. In case you are sharing this info, would recommend posting it in the Community Wiki. Thanks.
@r2rd You might want to review the sailpoint.web.system.SMSResetConfigBean attached to the SMSReset xhtml page to understand if there is a way to customize it or not. May be you can create a new bean and try attaching it to the xhtml page.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
,
, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.