Today we introduce a subtle but handy change by extracting Call URL’s Authorization section into separate entity: Third-party accounts.
Authorization block embedded directly into Call URL action served as well, but as we extend TeamDesk workflow functionality and integrations with third-party systems become more complex it starts to pose a problem.
An example
Consider Google Calendar synchronization. There is the webhook. You should first subscribe your webhook to receive change notifications. Then calendar calls the webhook and you should request the list of changes. Then for each event in the list get the event’s data. Finally, if you want to pause syncing you should unsubscribe your webhook.
Altogether you’d need a Webhook and four Call URL actions: Subscribe, List, Get and Unsubscribe. All four require a read-only API access to your calendar.
Now, suppose you finished testing synchronization with your calendar. Now you want to use shared one, available through different account. What do you need? Accurately change access credentials for each of four actions. Because if you forgot one, synchronization may go awry.
For Basic authorization you can store shared login and password into application variable and pass it to the service using headers. The downside of this approach is that login credentials are stored in a plain text. However, variables approach won’t work for OAuth 2 protocol. It uses an access token with a limited lifetime that rotates periodically and requires special treatment baked into Call URL actions code.
The solution: Third-party Accounts
So, we added new Third-party Accounts list on a database level. You can find it in Setup | Database tab | Tools | 3rd-party accounts. There you can set authorization type, usernames, passwords and tokens and then reuse the same account in multiple actions. You can now pick up an existing account in Call URL action’s interface if there is any suitable.
Or you can create new one without having to leave action UI.
We converted authorization of existing Call URL actions to Third-party accounts, one account per action.
As a bonus, Third-party accounts support new authorization type: Tokens.
Enjoy!
Thanks for continually improving the product. This is a great time saver.
I’m looking forward to implementing this feature. It will probably be very useful.
I love it !
We can put appropriate names to record modifiers when using triggers (rather than the name of the administrator of the base).
And it comes for free !
I first misunderstood the utilization of this feature.
Does it speed up OAUTH authentification (when making hundred OAUTH calls in a row, do we have only one authentication process ?)
Kind regards
After completing OAUTH 2 flow invoked by Authorize button we get back two tokens. Access token is time-restricted and is used directly for API access. Refresh token is used to get new access token once old is expired. With third party accounts expired access token refreshment will be performed once per account.