In this article you will learn:

  • How to setup Salesforce to accept connections from a Betty Block application
  • How to setup an OAuth flow from a Betty Blocks application to Salesforce
  • How to use access tokens and refresh tokens to connect to Salesforce webservices.

You will need the following prerequisites to use this tutorial and set up a new integration with Salesforce:
1 A Salesforce (demo) account
2 A Betty Blocks application (in this example we will use

Setting up Salesforce

Step one is to register your Betty Blocks application Salesforce App Integrations section. To do this, visit your Salesforce application and go to Platform Tools -> Apps -> App Manager.

Create a 'New Connected App'. Enter the required data in the form:

  • App name
  • API name
  • Contact Email

Make sure you tick 'Enable OAuth Settings'.
Add the following settings in the OAuth section:

  • A callback url. This has to be a url of the endpoint where Salesforce can send you an authorization code for the OAuth flow. In this example the url is
  • The selected OAuth scopes you want the user to have access to. Choose at least for the 'Perform requests on your behalf (refresh_token, offline_access)' option so that your users will have to perform the OAuth authorization flow only one time.

Save the application.

Save the Consumer key and Consumer secret in your Betty Blocks application as custom configurations (Settings -> Configurations) so that you can use them later:

Also create an application variable (Tools -> Variables) that loads the consumer_key and consumer_secret. This way you can use it in any template or action without having to define it everywhere you want to use it.


1 Create a Data Model
Users that are authenticated for Salesforce get an access token and a refresh token so that you can communicate via webservices with the access token of a user. Therefore we are going to store the access token of a user once he has successfully authenticated with Salesforce using the OAuth 2.0 flow.

To store the access token we create a Data Model in the application called OauthToken with the following properties:

2 Create a web page to initiate the OAuth 2.0 flow
To connect the application with Salesforce we need to initiate the OAuth 2.0 flow from a web page using a redirect or a button with a link to the OAuth consent screen of Salesforce. After successful authentication, Salesforce will redirect the user to the provided callback URL with a code parameter. With this code parameter we will be able to retrieve the user's access token for further use.

First create a webpage (using either the UI Builder or Custom HTML) and add a link or button on the page to redirect the user to the Salesforce OAuth 2.0 Consent screen. The URL looks like this:{{salesforce_clientid}}&scope=api full refresh_token&redirect_uri=

Please note that the 'eu11' part of the url depends on the zone of the Salesforce platform that your Salesforce implementation is running in. You can see the correct zone for your integration within the address bar when visiting your Salesforce app.

Also note that the redirect uri has to be exactly the same as the redirect uri you specified in your connected app settings on Salesforce. Otherwise it will result in a redirect uri mismatch error when trying to login.

3 Create a webpage to handle the authorization_code and retrieve the access token
Salesforce redirects the user back to the specified redirect uri with a parameter named 'code'. With this code you can retrieve the user's access- and refresh code for further use in the webservices.

To handle this code parameter and retrieve the access token we need to create a page endpoint with the same url as the redirect_uri (in this case /oauth/callback

Create the endpoint, use Custom HTML, method 'GET'. Specify one input variable with the name code:

Now also attach an action to this endpoint to retrieve the access token.

4 Define the Salesforce webservice and webservice endpoints.
Retrieval of the access token is done with a webservice connection. To be able to use this webservice, specify it in your application under Tools -> Webservice.

Create a new webservice, specify the Name, Protocol (HTTPS) and Host ( 

Again, use the correct zone of the Salesforce application you are connecting to. Save the webservice and create a new WebService Endpoint for retrieval of access tokens.

This webservice endpoint should look like this:

Choose 'New' for the Custom model in the webservice endpoint. Betty Blocks will create a new Custom model and attaches it to the webservice. Specify the following attributes on this custom model:

5 Call the webservice from the callback endpoint action and save the access token
Switch back to the endpoint /oauth/callback and go to the action. Add a new event with the kind Http request. Choose the Salesforce webservice and 'retrieve access token' webservice endpoint.

Then add a create event and store the access token retrieved from Salesforce.

The now expression variable in this screen is a Date time expression with the value now as expression. It will save the timestamp the access token is retrieved. As you can see the access token is saved but also the refresh token. With the refresh token you can request a new access token should it be expired since access tokens usually have a short lifetime.

Now also add a render html web template event to display a success message to the end user. Your action should now look like this:

6 Try the webservice flow to retrieve your first access token!
Visit the frontend page from step 1 and click the link or button you created there. You should be redirected to Salesforce and be asked to give You application permission to connect with Salesforce.

After this you will be redirected back to Betty Blocks and if all went well, the access token will be created. You can view the list of all access tokens easily by adding a grid view in the backoffice section of your application:

7 Now use the access token to retrieve data from Salesforce!
Salesforce supplies a wide range of available webservices you can use to retrieve data from or push data to the Salesforce application. In this example we are using the 'List accounts' webservice as an example.

Go to Tools -> Webservices again and add another webservice endpoint to the Salesforce webservice called' 'Account list':

Try to run test and use the access token from the previous step to fill in in the Authorization header preceded by 'Bearer '. So the authorization header should look something like this: Bearer 00D0Y0000033FTd!AR8AQIqNeco.....

If the response was ok you will see a response body and you can create a custom model based on this response automatically by pushing the button 'Generate Custom Model'.

Betty Blocks will automatically create a structure based on the JSON response from the test run.

8 Use the account list in an action
Now that you have defined the webservice endpoint and custom model structure for the account list you can use this webservice in any action within you application.

For example when you have a webpage where you want to display the list of accounts from Salesforce, just add a new WebPage (UI Builder or Custom HTML) and attach an action to it.

You can now use the response from this webservice to display on your webpage.

9 Refresh access tokens.
In normal OAuth flows, an access token has a short lifetime and expires after a specified amount of time. As soon as you try to make a webservice call with an expired token, you'll get an error message because the token has expired. To prevent this error you can use the refresh token to retrieve a new access token before making the actual webservice call.

Add a new webservice endpoint again to do this called 'Refresh access token'

Also, attach a Custom model to this webservice endpoint with the following attributes:

Now, go to actions and create a new Action on the OauthToken model to refresh the access token:

The first event in the action calls the Salesforce webservice to get a new access token and looks like this:

The second event will update the OauthToken record with the new access token:

Now you can call this action first every time you're going to do a call to the Salesforce webservice. For example in the account list action:

Now that you have this in place you can add any additional webservice endpoint that Salesforce provides!

Did this answer your question?