SOLVED
Right!
I didn't think about what '%2B' actually translated to. I guess the posts and documents I have been checking are centered around the US.
This is how I am thinking of setting it up (and we may end up doing it from Salesforce anyway, with more serious development so we can see message history and merge it with an sms functionality we already have on the lead record page):
(SMS as parent folder, AP and HF represent our two types of clients)
The webhook:
https://{{my.twilioSid}}:{{my.twilioToken}}@api.twilio.com/2010-04-01/Accounts/{{my.twilioSid}}/Messages.json
From=%2B1{{my.twilioFromNumber}}&To=%2B1{{lead.Phone Number:default=edit me}}&Body={{my.twilioMessageBody}}
I am using folder and program tokens. The parent folder includes the ID and token for the twilio account, I intended the country folders to include the 'From' numbers and the programs to include the message body token.
I was hoping to just create one webhook by doing this, instead of one per 'From' country or one per message (I really hope not :S )
Now I see that my template/payload is hard-coded to the US and I need to work on that.
The next problem I see is that our phone numbers aren't always in the right format. What would you suggest we do for this?
Of course validation is the right answer, but if that were not an option I was thinking of a script token that transforms numbers into the right format before the call is executed - I think you said script tokens don't work outside of the email context in some other post.
In that case perhaps another webhook that has been previously called and normalizes our phone numbers from the start or maybe even a Salesforce solution that kicks in on sync?
Do you see any other problems with a setup like this?
I have also been trying to map the response from twilio to a field in the template, but I haven't managed to access the right element in the response as explained here. In any case, I have been able to have a look at the logs in twilio and I think the first element in the response I would be interested in would most of the time always say 'queued', which is not what I want to see. I want so see 'sent' or an error message.
Even if I got that right, we couldn't see the history, only the most recent log... I don't know, this all feels like an MVP at best.
Hi @SanfordWhiteman ,
Thanks for your reply.
I did eventually see their lookup product, of course paid 🙂 . But you do say it is reasoably priced... so we will keep it in mind. I bookmarked your article about setting it up as webhook.
I also found something on github a long time ago that does exactly that: input a phone number, outputs the number in different formats and other metadata like landline or not... not sure if carrier though. Probably unsafe to use directly and probably would get out of date without maintenance... ?
Eventually I also figured out how to map response attributes, only I'm mapping single ones... is there a way to map the whole response to a field?
I tried things like
to try to emulate what is explained here. But the response from Twilio doesn't follow that structure...
{
"sid": "SM####################################",
"date_created": "Tue, 16 Jun 2020 12:56:47 +0000",
"date_updated": "Tue, 16 Jun 2020 12:56:47 +0000",
"date_sent": null,
"account_sid": "AC################################",
"to": "+41#########",
"from": "+41#########",
"messaging_service_sid": null,
"body": "subscription settings",
"status": "queued",
"num_segments": "1",
"num_media": "0",
"direction": "outbound-api",
"api_version": "2010-04-01",
"price": null,
"price_unit": "USD",
"error_code": null,
"error_message": null,
"uri": "/2010-04-01/Accounts/AC##############################/Messages/SM###################################.json",
"subresource_uris": {
"media": "/2010-04-01/Accounts/AC#########################/Messages/SM###############################/Media.json"
}
}
Also thanks for the webhook was called tip i was using that to create a history of 'sent' and 'failed' events.
The change data value token looks like this:
[{{system.dateTime}}] Delivery failed | {{lead.SMS History (Mkto):default=edit me}}
Which results in a story field with concatenated entries like these:
I'm wondering what happens if you keep doing this and reach the field's character limit...
The hardest part is the 'delivered' status. For that it seems a whole web service is needed (you mention this in one of your posts), which doesn't seem to be too complex, but definitely too complex for me at the moment.
is there a way to map the whole response to a field?
Only if you use a webhook aggregator. A couple of my recent blog posts discuss that approach.
The change data value token looks like this:
[{{system.dateTime}}] Delivery failed | {{lead.SMS History (Mkto):default=edit me}}
Which results in a story field with concatenated entries like these:
I'm wondering what happens if you keep doing this and reach the field's character limit...
It just wouldn't update anymore (the text would be truncated).
.png)