Salesforce is an enterprise-level cloud computing platform used for customer relationship management and other “big data” needs. By using Skuid in conjunction with Salesforce data, it is possible to create intuitive user interfaces that pull in an organization’s data—perhaps while pulling in data from other services as well. It is the default data source available in any Skuid on Salesforce instance, but additional data sources can be configured to connect to Salesforce orgs.

For Salesforce users working in larger organizations, there may be multiple orgs, with different types of data, that need to be accessed at various times. Accessing different orgs and modifying data in each can be cumbersome, requiring different login credentials and (sometimes) different platforms.

With Skuid’s Salesforce data source type, accessing multiple Salesforce orgs is far simpler. In Skuid, creating a Salesforce data source for each external org does not require copying data or cloning objects between orgs. Instead, Skuid authenticates to an external org (or orgs) using a configured authentication provider and data source in a process similar to other external data connections. Once your data sources are in place, users will be directly reading, creating, and updating data on multiple orgs, all from the same Skuid page.

What’s an “external org?”

If you’re using Skuid Platform, all your data sources, including Salesforce, are “external” to your Skuid site and are accessed via data sources you create.

If you are using Skuid on Salesforce, however, you are working within a specific Salesforce org, on which Skuid was installed as a managed package. Perhaps you’re in sales at Acme Industries, so the Salesforce org where you work within your Skuid pages might be If you want to pull data into those pages from another Acme Salesforce org (for example, to get invoice data from the Accounting Department’s org,, you must create a data source that connects to this “external” org—external to the Salesforce org hosting your Skuid pages. You must also create the connected app (see below) in that external org to facilitate this connection.

Connecting to more than one external Salesforce org from your Skuid site? You’ll need to create a connected app within each external org, as well as a data source for each within your Skuid site.

Just remember: everything described below is about connecting to an external org from your Skuid site, whether that Skuid instance is on Platform or Salesforce.

Set up a Salesforce data source

To use the Salesforce data source type with Skuid, you’ll need to complete the following three steps for each external org you want to access:

  1. On the external Salesforce org: Create a Salesforce connected app on the external org
  2. On Skuid: Create a Salesforce authentication provider that uses the credentials from the connected app created in the external Salesforce org.
  3. On Skuid: Create a Salesforce data source—which uses the authentication provider to authenticate—to facilitate a connection to the external Salesforce org.

Best Practices

Before you start

  • You must have the latest version of Skuid installed in each external Salesforce org you will be accessing.
  • You must have licensed Skuid user credentials for each external Salesforce org you will be accessing. These user credentials must match the credentials used to pull the data; use the same Salesforce/Skuid credentials throughout this process.


Within the Salesforce universe, the term “Skuid license” refers to a user’s ability to interact with Skuid. While the Skuid UI reflects this terminology to avoid confusion, the “number of Skuid licenses” you have refers to purchased Skuid subscriptions.

  • My Domain must be enabled on any Salesforce Org you will be accessing. While the org’s instance-based URL (e.g. will technically work, using it is not recommended since this URL is subject to change when Salesforce performs instance migrations. My Domain is free and available on all Salesforce orgs that can run Skuid. Configure your org’s My Domain settings by navigating to Setup > Domain Management > My Domain. To learn more, see Salesforce’s My Domain documentation.
  • Skuid models and pages can not be retrieved using this data source type. If you wish to use pages across orgs, you’ll need to recreate the pages, use Page Packs, or use skuid-grunt (a developer tool for distributing Skuid pages). These step are not necessary for your Salesforce connections to work.

A few caveats

  • Salesforce permissions are retained in all data source connections; a user can only see and edit data they have access to in the associated orgs. Ensure that Salesforce user permissions are appropriately set in each external org being accessed.
  • If two people are simultaneously editing an external Salesforce org’s data, the last edit wins.


To prevent errors, do not set up multiple data sources pointing to the same external Salesforce org while within your current Salesforce org.


In the external Salesforce org

Set up a Salesforce connected app

To connect to an external Salesforce org using OAuth (or any other method), you need to create a connected app within that org that functions as a configurable gateway to your data. You’ll need to do this only once.

If you have already configured a connected app, you may use that one if its settings match those listed below. If so, proceed to In Skuid: Create the authentication provider.


To connect to multiple Salesforce orgs, repeat the steps below for each external org.

Create a Connected App:

  1. In your external Salesforce org, from the Salesforce Setup pane, navigate to Build > Create > Apps.

  2. Under Connected Apps, click New.

  3. In the New Connected App page, enter the app’s basic information:

    • A unique Connected App Name.
    • A Contact Email.
  4. Check Enable OAuth Settings. Once you’ve done this, additional fields appear:


    If you’ll be accessing this external Salesforce org from multiple instances of Skuid, enter each Skuid site callback URL on a new line, without commas.

    • Selected OAuth Scopes: Click and add the following OAuth scopes to facilitate Skuid interacting with the Salesforce external org’s data:
      • Access and manage your data (api): While appearing as a sort of “belt-and-suspenders” approach, including the api scope in addition to the full scope is recommended to avoid OAuth scope errors.
      • Perform requests on your behalf at any time (refresh_token, offline_access): This scope allows users to login to the org once, as opposed to every several minutes.
  5. Click Save.


It may take a few minutes for Salesforce to create the app.

Callback URLs

Callback URLs tell the connected app in the external Salesforce org where in Skuid to send data. Because of this, the callback URL listed in the external org connected app should point to your Skuid site. Without the proper callback URL, the external org cannot send data to the proper location.

See the examples for your platform of choice below:

Skuid Platform [[]]

For Skuid Platform sites, simply append /auth/oauth/callback to your Skuid site’s domain URL.

Some examples:

  • For, use
  • For, use
  • For, use

Skuid on Salesforce [[]]

When using Skuid on Salesforce, the callback URL will depend on several things:

  • Whether or not the Remove Instance Names from URLs critical update is activated
    • If the above critical update is not activated, then the Salesforce org’s instance
  • If set, the Salesforce org’s My Domain
  • Whether the org is a developer edition or sandbox org

Each of these variables will change parts of the callback URL.

There are also different URLs needed based on whether the Skuid page is deployed using the Redirect or skuid:page Visualforce component override method. Because of this, it’s best to enter two callback URLs for Skuid on Salesforce orgs.

To ensure the accuracy of your callback URLs, fill out the form below to generate the appropriate Salesforce callback URLs for your org:


Unsure what your instance and My Domain are? The URL of the Skuid Pages list within the Salesforce Classic layout is a quick way to find the information needed for callback URLs. For example:

From the above URL you can deduce the following:

  • customMyDomain is the My Domain
  • -dev-ed indicates this is likely a developer’s edition org
  • na30 is the instance.

How these URLs are formed [[]]

If the Remove Instance Names critical update is activated, and the org’s My Domain is configured, the callback URLs should be:

  • https://<myDomain>
  • https://<myDomain>

If the org’s My Domain is configured, their format should be:

  • https://<myDomain>--skuid.<Instance>
  • https://<myDomain>--c.<Instance>.

If the org’s My Domain is not configured, then the URLs will be:

  • https://skuid.<Instance>
  • https://c.<Instance>

If the org is a developer’s edition or sandbox, the skuid/c section of the URL will be prepended with -dev-ed– or –sandboxName– respectively.

User access settings

With the connected app configured, you must now grant the appropriate users access.

If you wish to grant access to all users:

  1. In the Salesforce sidebar, click Manage Apps > Connected Apps.
  2. Click the master label of the connected app.
  3. Click Edit Policies.
  4. Set the Permitted Users field to All users may self-authorize.

If you wish to specify the users who will be accessing data through the connected app, give them the following permissions:

  • Assign users the Connect to this org’s data using Skuid permission set:

    1. Navigate to Manage Users > Permission Sets > Connect to this Salesforce org’s data using Skuid.


      This permission set’s API name is Connect_to_this_Salesforce_orgs_data_using_Skuid.

    2. Click Manage Assignments.

    3. Click Add Assignments.

    4. Select the appropriate users.

    5. Click Assign.

  • Ensure users are API Enabled, either through their profiles or a permission set.

    • Profiles


      You cannot update the administrative permissions for standard profiles. If you do not wish to use custom or cloned profiles, the use of permission sets is recommended.

      1. Navigate to Manage Users > Profiles.
      2. Click Edit beside the profile that requires access.
      3. Check the API Enabled box under the Administrative Permissions pane.
      4. Click Save.
    • Permission sets

      First, create a permission set with the API Enabled setting.

      1. Navigate to Manage Users > Permission Sets.
      2. Click New.
      3. Enter an appropriate label for the permission set, such as API Enabled.
        • The API Name field will be generated from the label.
      4. (Optional) Add a description for the permission set.
      5. (Optional) If you are certain that only a specific license type will be accessing data through the connected app, you may select that in the License field. Otherwise, leave the value as –None–.
      6. Click Save.
      7. Click System Permissions.
      8. Click Edit.
      9. Check the API Enabled box.
      10. Click Save.

      With the permission set configured, assign it to all appropriate users. If you have not assigned permission sets before, please refer to Salesforce’s documentation.

  • Finally, grant users access to the connected app itself either through their profiles or a permission set.

    • Profiles

      1. Navigate to Create > Apps.
      2. Click Manage beside the connected app.
      3. Click Manage Profiles in the Profiles pane.
      4. Select which profiles should have connected app access.
      5. Click Save.
    • Permission sets

      First, create the permission set for the connected app.

      1. Navigate to Manage Users > Permission Sets.
      2. Click New.
      3. Enter an appropriate label for the permission set.
        • The API Name field will be generated from the label.
      4. (Optional) Add a description for the permission set.
      5. (Optional) If you are certain that only a specific license type will be accessing data through the connected app, you may select that in the License field. Otherwise, leave the value as –None–.
      6. Click Save.
      7. Click Assigned Connected Apps.
      8. Click Edit.
      9. Click the connected app you’ve created to select it.
      10. Click Add fa-caret-right to assign the connected app to the permission set.
      11. Click Save.

      With the permission set configured, assign it to all appropriate users. If you have not assigned permission sets before, please refer to Salesforce’s documentation.


With the settings saved, retrieve the credentials needed for a Skuid authentication provider.

  1. From Salesforce Setup pane, navigate to Build > Create > Apps.
  2. Under Connected Apps, click the app you just created.
  3. Under API (Enable OAuth Settings), find:
    • The consumer key
    • The consumer secret (click to reveal)

If you need to find these later, navigate in Salesforce’s Setup pane to Build > Create > Apps, and open the connected app’s page.

In Skuid site

With the connected app setup in the external Salesforce org, you’ve completed all the external configuration. All that’s left is creating an authentication provider and data source within your Skuid site.


As above, you’ll need to complete these steps for each external org you connect to.

Create the authentication provider

  1. Navigate to Configure > Data Sources > Authentication Providers.
  2. Click New Authentication Provider.
  3. Fill out the necessary fields:
  • Name: Enter a unique name, such as SalesforceAuth.


If using more than one org, for the sake of clarity, make sure this identifier also indicates which org is being accessed.

  • Authentication Method: OAuth 2.0/OpenID
  • Provider Type: Salesforce
  • Grant type: Select Authorization code if you would like users to authenticate using their own Salesforce org credentials.


You can also share or use credentials stored within Skuid, which we’ll cover below.

  • Authorize Endpoint URL & Token Endpoint URL: Enter the org’s My Domain for the external Salesforce org in the appropriate area. For example, if your Salesforce external org’s My Domain is “externalorg-dev-ed,” then the endpoint URLs would be:
  • Default Scopes: If not auto-populated, insert the following:
  • api,refresh_token,offline_access


    Do not add spaces.

  • Client ID: Enter the connected app’s consumer key.
  • Client Secret: Credentials: Enter the connected app’s consumer secret.
  1. Click Save.
  2. If Skuid asks to create a Remote Site Setting, click Ok.

Create the data source

Now that your authentication provider is configured, create a data data source that uses it to authenticate to the external org.

  1. Navigate to Configure > Data Sources > Data Sources.
  2. Click fa-plus-circle New Data Source.
  3. Select the Salesforce data source type.
  4. Enter a unique, easily recognizable name for your data source.
  5. Click Next Step.
  6. Enter the My Domain name for the external org, and the Salesforce API URL will auto-populate.
  7. Click Next Step.
  8. Select the authentication provider you created in the previous step.
  9. Click Save New Data Source.
  10. If Skuid asks to create a Remote Site Setting, click Ok.

Share credentials or use credentials stored within Skuid (Optional)

In addition to authenticating using OAuth, you may also use the Resource Owner Password Credential flow instead. While OAuth is the recommended authentication flow, this authentication method allows you to share credentials org-wide/per-profile, or use other stored credentials.


When using this grant type, you may need to relax IP restrictions in the external org’s connected app.

  1. Navigate to Configure > Data Sources> Authentication Providers.
  2. Click Details fa-wrench beside your authentication provider.
  3. Change the Grant Type to Resource Owner Password Credentials.
  4. Navigate to Configure > Data Sources
  5. Click fa-sliders Advanced Settings beside your data source.
  6. Select the Credential Source that fits your use case. For more information, see the Basic HTTP Authentication section of Authentication and Skuid.
  7. Click Save.


Each user credential entered must have a Skuid subscription within the external orgs they will be accessing. If a user’s account on that external org is not assigned a Skuid subscription, they will not be able to access data from that org.

Update Scopes

If you are sharing credentials or using stored credentials, remove refresh_token from the scopes in both the data source and the connected app(s). Skuid won’t be able to get refresh tokens using this method, but receiving them is also not necessary since users will be providing credentials with each request.

Using the Salesforce data source in Skuid

When you have configured the connected app in Salesforce, as well as an authentication provider and data source in Skuid, you can freely connect to the external org’s data within Skuid pages. To do so, select the external Salesforce org’s data source for the models within Skuid pages:

  1. Navigate to an existing Skuid page or create a new one.
  2. Create a new model.
  3. For Data Source Type, select Salesforce.
  4. Select the data source you configured for your external org.
  5. In the Salesforce Object Name field, enter the name of the Salesforce object the model should access.


This field is only searching the selected external org—objects from your current org will not appear or be accessible from this particular model!

And with that, data from the external Salesforce org functions just like any other data source.

Model Properties

The following model properties are exclusive to the Salesforce data source type:

  • Basic

    • Model Behavior: Determines whether a model will function as a basic model ( the default Skuid behavior) or as an aggregate model, which summarizes multiple rows of data into aggregations.
  • Advanced

    • Clone data returned by Model query: When checked, all records queried by the model are cloned and treated as brand-new records. Any record updates are not applied to currently existing records, but saved as totally separate records.

      Can be useful for testing but not typically recommended for production applications or mission-critical data.

    • Query Deleted / Archived records: Overrides the standard functionality of the Deleted and Archive features of Salesforce objects to retrieve all records, including those that have been deleted or archived. This option adds the “ALL ROWS” clause to a SOQL query submitted by the model. By default, this clause is not added to the query.

    • Update Salesforce “Recently Viewed” info: When checked, the LastViewedDate field will be updated whenever a record is changed within the model, meaning the record will show in the Recently Viewed or Recent Items sidebar on a typical Salesforce page.

    • Process Model client-side: When checked, the model’s data will be handled within the browser as opposed to exclusively on Salesforce servers.


      If using page caching, then we highly recommend that you check this box unless this model’s object data rarely changes. If this property is unchecked and the page uses page caching, then this model will potentially present stale object metadata/data.

Using File Upload with the Salesforce data source

The File Upload component has specific properties that are only available when used with a Salesforce data source type.

Using File Upload with Lightning Experience [[]]

With the Salesforce Spring 17 release, Salesforce warned that it is changing the way it handles attaching files to records in the Lightning Experience.

Skuid does not know when Salesforce will make this change official, but recommends that app builders factor this information into their page development plans. Consider upgrading to a newer version of Skuid to take advantage of uploading to the Content Document object.

Salesforce currency field support

Parenthetical Currency Conversion is supported within Skuid. However, Skuid does not support Advanced Currency Management.


Enabling Advanced Currency Management will cause unexpected behaviors within your Skuid components.

Data Source Actions

Use data source actions to add more functionality to applications. Skuid supports both standard Salesforce invocable actions (post to Chatter, enable folder, send email, submit for approval), or customs actions created using Apex, Flow, Quick Action or Email Alert.


Skuid on Salesforce: Salesforce data source actions will not run within the Skuid Page Lightning component in this version of Skuid. If using Salesforce data source actions in Lightning Experience, consider deploying Skuid through a Visualforce page override.

For more information, see the Salesforce Classic deployment topic.


Each time a Salesforce data source action is called, a Salesforce API call is made—even when using Skuid on Salesforce in the same org. If API usage limits are a concern for your org, balance the use of these action types and the API limits of your org. For information on API usage limits, see the Salesforce Developer Limits Quick Reference.

The Salesforce data source type includes the following data source actions:

  • Post to Chatter: Posts a message at runtime to a specified Chatter feed.

  • Enable Folder Support for Content Workspace (Library): Enables folders in SF Content library.


    To use this action, you must have the ID for a ContentWorkspace on Sales-Cloud.

  • Send Email: Sends an email in which you specify the subject, body, and recipients.

  • Submit for Approval: Submits a Salesforce record for approval.


    An Approval Process must be defined for the entity.

  • Apex: Invokes Apex methods within Skuid.


    To be used with this action type, Apex code must contain InvocableMethods, as well as InvocableVariables for fields within those methods.

  • Flow: Invokes an active autolaunched flow or invocable process. (This flow or process must already exist within the org.) The flow action allows Salesforce Administrators to declaratively develop invocable processes.

  • Email Alert: Sends emails from flows by reusing pre-configured workflow email alerts.

  • Quick Action: Creates a task or case; can be used to create or update records or log calls.

Using the Apex action

All properly-annotated invocable methods will appear within the Apex Action field picklist; the first method that Skuid detects will likely be selected automatically. If you do not see your method, try refreshing the App Composer.

As with other Skuid fields, invocable variables can point to various fields with the use of merge syntax.


Only authenticated Salesforce users may access invocable methods and run Apex actions. Using this action type within a Skuid page on a public-facing site or community is not recommended, as guest users will not have the permissions for proper functionality.

Merge variables for Apex action information

There are two merge variables unique to the Apex action that allow you to utilize information returned by current and previous actions.

{{$CurrentAction.error.message}} displays any error message returned by the current Apex action as a string. This error message may not display within Skuid, so it can be helpful to use this merge variable in an on-error action, perhaps in a Show message and block UI action.

$PreviousAction is used for retrieving information from a previous Apex action in the current script of actions. To retrieve a field returned by an Apex action, use {{$PreviousAction.result.<fieldName>}}, where <fieldName> is the field you wish to access. For example, if the Apex class returns a message you wish to display, you would use {{$PreviousAction.result.message}}.


If your Apex action returns a list of SObjects, you may find your results nested within {{$PreviousAction.result.output.<fieldName>}}.

Because this merge variable depends entirely on the context of a previous action, it should only be used in a script of actions after an Apex action. If there is more than one Apex action in the script, $PreviousAction will display results from the most recent Apex action.

Using $PreviousAction requires knowledge of what Apex is returning. Because of this, it can be helpful to see what Skuid receives at runtime:

  1. Preview the Skuid page.
  2. Open the Network inspector within your browser of choice:
  3. Initiate the Apex action.
  4. Click the network request for the Apex action. The request will typically be named after the Apex class containing the invocable method.
  5. Preview the network response.
  6. Investigate the outputValues node to see what Skuid receives. You can use each of these fields with $PreviousAction.

More about Salesforce data source actions

For more information on using these data source actions, visit the REST API Developer Guide Invocable Actions and Introducing Actions sections, or review the Actions Developer Guide.

If your data source actions do not seem to be working see this troubleshooting section.

Salesforce API Usage

When using Skuid on Salesforce, Skuid is a managed package installed within a Salesforce org. This means that almost every action Skuid takes does not consume API calls for the org it is installed in. However, there are some exceptions:

  1. Page support file generation for LockerService compliance will consume API calls.

  2. Any use of Salesforce data source actions will consume an API Call.

  3. Record type dependent picklists require an API call to confirm the available picklist values. Skuid aggressively caches to avoid consuming API calls, but some calls will still be incurred.


    If you have dependent picklists but do not have record types, those picklists will not consume an API call.

For both Skuid on Salesforce and Skuid Platform, accessing an external org’s data—whether through model queries or Salesforce data source actionswill consume API calls in the external org.


URI Mismatch

An OAuth popup window will appear when you first attempt to access the external org’s data objects. If that popup contains the following error message:


The callback URL within the external org’s connected app may be improperly configured.

  • Ensure that the callback URL points to your Skuid site and that there are no typos. Some callback URLs have double underscores; a single underscore will throw an error.
  • If your callback URL is correct—and you are using Skuid on Salesforce to access the external org—check your Skuid site’s remote site settings—there must be one configured for the external org you are accessing. You can find these settings by navigating to or searching for Administer > Security Controls > Remote Site Settings in the Salesforce sidebar.
  • While Skuid creates these remote site settings by default, an error may have prevented it from saving. Click New Remote Site if you do not see a setting for the external org.

OAuth Approval

If your OAuth popup displays a Salesforce error page with the following message …


… the scopes for your connected app in the external org and your data source in the Skuid site may not be properly configured. Ensure that both contain the api scope, and that the scopes match exactly for both configurations.

If you are still receiving errors, add the Full access (full) scope to both the external org’s connected app and the Skuid site’s authentication provider.

OAuth popup hangs with success message or does not appear

The OAuth popup may display the following message without closing:

You have been successfully authenticated! This window should close momentarily...

The popup also may not appear at all. In both instances, authentication is unlikely to be successful.

This may be related to the Skuid page residing in a different namespace than expected. To resolve this issue, you may need to set a Custom Callback URL in the authentication provider—functionality that is only available in Skuid versions 10.0.0 and above—as well as clone Skuid’s oauthcallback Visualforce page. To do this:

  1. Return to the authentication provider and update the following field:

    • Custom Callback URL: /apex/oauthcallback
  2. Click Save.

  3. Copy the Skuid’s oauthcallback Visualforce markup below:

    <apex:page showHeader="false" sidebar="false" showChat="false">
      window.skuid = {
        platform: {
          getOAuthProxyUri: function(){
           return window.location.origin+(window.$A?'/skuid/':'/apex/ skuid__oauthproxy');
        <script src="{!URLFOR($Resource.skuid__JqueryJS)}"></script>
        <script src="{!URLFOR($Resource.skuid__OAuthClientJS)}"></script>
        You have been successfully authenticated! This window should close momentarily...
  4. Next, create a new Visualforce page titled oauthcallback. Paste the markup copied above into the Visualforce Markup pane.

  5. Click Save.

Errors when selecting external Salesforce objects for a model

You may see following error message when trying to select a Salesforce object for a model’s object in Skuid:

403 Forbidden: You do not have access to the Apex class named: RestServices_Model



This error is typically related to permissions. If users entering proper credentials are seeing these errors, verify each of the following requirements within the external org to ensure that users have the proper permissions for Salesforce data connections.

  • Verify that all connected app settings are correct, as listed in this tutorial’s first section
  • Double check that all users attempted to access external data have the appropriate permissions granted in the external org. All of the following must be true for all users accessing data:
    • The user is API enabled.
    • The user has the Connect to this Salesforce org’s data using Skuid permission set.
    • The use has access to the connected app.

For more information, see the User access settings section.

If the above steps do not resolve the error, you may need to relax IP restrictions in the external org’s connected app.

In Salesforce

  1. Navigate to Build > Create > Apps.
  2. Click Manage beside the connected app.
  3. Click Edit Policies.
  4. Set IP Relaxation field to Relax IP restrictions or Relax IP restrictions with second factor.
  5. Click Save.

Invalid Request: Argument cannot be null

This could mean that the Salesforce authentication provider is set to the Resource Owner Password Credentials grant type, but no user credentials are provided. Verify that the Skuid admin updating the model has a Salesforce username and password set in the My Credentials tab.

Authentication Failed

This could indicate a mismatch between the scopes in the Salesforce authentication provider and the external org’s connected app. Verify that Default Scopes listed in the authentication provider exactly match the scopes listed in the connected app.

Invalid client

If your OAuth popup displays a Salesforce error page with the following message …


This error indicates that the customer key or secret may not have been correctly entered within the Skuid site’s authentication provider. Re-enter these credentials.

401 error when selecting external Salesforce objects for a model

This error indicates the credentials for your external org’s connected app and your Skuid site’s authentication provider may not match. Recreate your Skuid site’s authentication provider, and if the error persists, recreate your external org’s connected app.

Data source actions do not work

Action types—particularly data source actions—may receive error information from the data source that is not directly displayed on the Skuid page. While this information is available within the Network tab of a browser’s dev tools, this can be unhelpful in diagnosing problems for the end user.

If your end users are seeing actions that do not seem to be behaving correctly, try adding an on-error action with a special merge variable to display any received error message.

  1. Click the problematic data source action.
  2. Click fa fa-exclamation-circle Add on-error Action.
  3. Click the Show message and block UI action type that is created by default.
  4. For value, enter {{$CurrentAction.error.message}}.
  5. Click Save.

A message will display the network error Skuid received to the end user—allowing for more accurate debugging.