Third-Party Accounts

Third-party accounts are an extracting Call URL Authorization section into separate entity.

Using the Third-Party Accounts functionality you can set authorization type, usernames, passwords and tokens and then reuse the same account in multiple Call URL actions.

To create a new 3rd-Party Account, navigate to Setup >> Database tab >> Tools >> 3rd-Party accounts, click New button.

As the result, you’ll see the New Account form.

Property	Description
Name	In the Name field enter the name of 3rd-Party Account.
Notes	The Notes field can hold any developer’s comments that need to be kept for this 3rd-Party Account. The comments will be visible only in the Setup mode.
Type	In the Type dropdown you can choose an authorization type. The following types are available: Basic Access Token Google Microsoft Generic OAuth v2 When the authorization type is selected, the list of corresponding fields like Username, Password, Token etc should be filled in. The Google or Microsoft options in the Type dropdown are only available for the main TeamDesk domain. Other domains should use Generic OAuth v2 options. The OAuth2 protocol requires an "app registration" part on the third-party site -- there you'll obtain the Client ID and Secret values used further in authorization process. The integral part of app registration is "Redirect URL" -- a page on TeamDesk that the third party service calls back with authorization code. This page is https://<yourdomain>/secure/oauth.aspx. Since the domain part is variable we can't register apps for all the variety of subdomains - you have to register an app for your own subdomain.

You can reuse the same 3rd-Party account in multiple Call URL actions. Moreover, a new 3rd-Party account can be created directly in a Call URL action form.

The Example

Let’s 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.

Next: E-mail Non-Delivery Report