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 SFX 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, end 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 NLX, 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 SFX, 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; an end 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 end 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:

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

Some examples:

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

User access settings

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

If you wish to grant access to all end 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 end 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 end users. If you have not assigned permission sets before, please refer to Salesforce’s documentation.

  • Finally, grant end 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 end 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 end 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.

Metadata Caching

Metadata explains the structure of your data to Skuid. And because it’s such an essential part of the data model, metadata is unlikely to change after initial set up. However, Skuid must still query for metadata at every page load.

As an alternative, it is possible to cache, or save, the metadata of Salesforce data sources for future use instead of downloading it on each page load. Doing so can lead to noticeable performance improvements.


  • You must refresh your metadata cache manually if your Salesforce schema changes.
  • While it’s still possible to cache Salesforce metadata, performance gains will not be seen within Lightning Experience due to browser memory limitations.

Enable metadata caching

  1. Navigate to Configure > Data Sources > Data Sources.
  2. Beside any Salesforce data sources, click fa-cogs Configure Data Source.
  3. Within the data source’s detail page, click Enable Metadata Cache fa-history.

With metadata caching enabled, Skuid will store the metadata for that particular data source—greatly improving load times on any pages that use it.


It is important to note that Skuid will only cache the metadata that the Skuid admin has access to within the Salesforce system. If the admin that enables caching does not have access to any objects on the system-side, then that metadata will not be cached.

It is recommended that a buider with full Salesforce permissions be the Skuid admin to enable caching.

Refresh the metadata cache

Skuid cannot detect that a data source’s metadata has changed—such as when a new object or field is created—and it will not automatically re-cache the metadata.

To ensure the cached metadata is up-to-date—or if you know the data source’s metadata has changed recently—you’ll need to refresh the cache:

  1. Navigate to Configure > Data Sources > Data Sources.
  2. Beside any cached Salesforce data sources, click Refresh Metadata fa-refresh.

Doing this will cause Skuid to re-download the metadata from that data source, grabbing the most recent updates in the process.


As with enabling metadata caching, ensure that a fully permissioned user refreshes the cache in Skuid. If the Skuid admin does not have access to a previously cached metadata object, that object will be deleted when the cache is refreshed.

Disable metadata caching

To disable and delete Skuid’s metadata cache for a data source:

  1. Navigate to Configure > Data Sources > Data Sources.
  2. Beside the cached data sources, click Disable Metadata Cache fa-chain-broken.

This will clear Skuid’s cache of any stored metadata. You can re-enable caching at anytime by clicking Enable Metadata Cache fa-history.

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 unique to the Salesforce data source type:

  • General

    • 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.

    • Auto-sync with other Lightning Components: When checked, the model will send out and respond to events that update Salesforce data. This automatic synchronization works between models on Skuid pages in the Skuid Page component and standard Lightning components.

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.

The impact of these changes in Skuid will be:

  • In the future, using the Attachment to Record file storage location will not be supported in Lightning Experience.
  • Instead, use the In Content Document (with Record Context) option as the file storage location. This option is supported in Lightning Experience.
  • Files previously stored as Attachment to Record still display in the Salesforce Notes & Attachments; they cannot be “moved,” but if they are files that have been stored in Salesforce, end users can upload the files into the Files list.

While these changes will impact Salesforce Lightning Experience builders and users specifically, Skuid best practice is to adhere to these recommendations for all Skuid pages.

This is also the best practice for allowing a parallel file attachment experience between an enterprise’s Skuid users and Lightning Experience users.

Salesforce currency field support

  • Parenthetical Currency Conversion is supported within Skuid.

  • Advanced Currency Management (ACM): Skuid does support data entry while ACM is enabled within an org, and entered data will be converted to the org’s base currency. However Skuid cannot display existing opportunity amounts using dated exchange rate rules at runtime. Instead, Skuid uses the first conversion rate available for a currency.

    If you choose to enable this feature be aware that users may see conflicting historical data that does not match what resides in the database.

Salesforce date functions

Skuid models on Salesforce objects with date/time fields use Salesforce’s own date function logic in areas like model conditions.


While many of Salesforce date functions are similar to Skuid’s own functions, they are technically not the same logic. Salesforce date functions are run by Salesforce, while Skuid’s functions are run by Skuid.

For example, Salesforce’s DAY_IN_WEEK and Skuid’s DAY_OF_WEEK have the same purpose, but Salesforce functions can only be used for Salesforce conditions; similarly, Skuid functions can be used with any other data source.

Data Source Actions

Use data source actions to add more functionality to applications. Skuid supports both standard Salesforce invocable actions and custom actions (which depend on the existence of custom metadata in the Salesforce org). Skuid also provides Skuid-defined options (such as some of the Approval Process actions) for additional customization.


Each time a Salesforce data source action is called, a Salesforce API call is made—even when using Skuid SFX 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.

Standard 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 recipients, sender, subject, and body.

Depending upon which release your org is using, you may have access to other Salesforce actions. See Salesforce’s Invocable Actions for more information.

Custom actions


There must be custom metadata in the Salesforce org for Custom Salesforce data source actions to function.

  • 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.

  • Load All Remaining Records: Loads all remaining records for a model’s object by querying in batches.

    • Batch Size: The number of records to query for in each batch. Should be a low enough number to avoid hitting query limits.
    • Step Message: The message displayed while Skuid queries each batch. Several merge variables can be used denote progress in this message property.
    • Finish Message: The message displayed after Skuid has queried all records for the model. Several merge variables can be used denote progress in this message property.
    • Cancel Model Changes: Determines whether or not any unsaved changes are discarded once the action begins.
  • Send HTML Email: Sends an email in which you specify the recipients, sender, subject, and plain text or HTML body.

Approval Process actions


For the data source actions below, an Approval Process must be defined for the object.

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

  • Approve: Approves a submitted record. (Only an assigned approver or a Salesforce admin can approve a record.)

  • Reject: Rejects a record that has been submitted for approval. (Only an assigned approver or a Salesforce admin can reject a record.)

  • Recall: Recalls a record that has been submitted for approval. (Only the submitter or a Salesforce admin can recall a record.)

  • Unlock Record: Unlocks a record for editing after the record has been submitted for approval. (Only Salesforce admin can unlock a record.)


    When records are submitted for approval, they are locked for edits. The Unlock action allows a record to be edited while in the approval process.


    To use the Unlock action, record locking/unlocking must be enabled in the Salesforce org.

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 Composer.

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


Only authenticated Salesforce end 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}} 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. Apex actions typically output a list of objects, and Skuid can retrieve data from the first object in that list with {{$PreviousAction.result.variableName}}. Some examples include:

  • An Apex class returns a custom Apex object type with a message invocable variable defined. That invocable variable could be accessed on the first object with {{$PreviousAction.result.message}}.
  • An Apex class returns a list of sObjects. The first sObject’s fields can be accessed with {{$PreviousAction.result.<fieldApiName>}}, where <fieldApiName> represents the field’s name as expected by Salesforce’s SOAP API. So {{$PreviousAction.result.FirstName}} could be used retrieve the First Name field of a Contact record returned by Apex.


Keep in mind that even though an Apex class may return a list of custom Apex objects or a list of sObjects, only the first object is accessible from this merge variable.

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.

Merge variables for Load All Remaining Records

The following merge variables may be used within the message properties of the Load All Remaining Records action to illustrate the progress of the action.

  • $CurrentAction.nextStartRecord: States the first record in the range of the current batch. E.g., if Skuid is working through its second batch of 50 records at a time, this value would be 51.
  • $CurrentAction.nextFinishRecord: States the last record in the range of the current batch. E.g., if Skuid is working through its second batch of 50 records at a time, this value would be 100.
  • $CurrentAction.totalRecords: States the total amount of records loaded by a Load All Records action. Can only be used in the Finish Message property.

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.


Using dependent picklists [[]]

When using dependent picklists with the Salesforce data source type, be sure to include the controlling field in the model. Failing to do this will result in unexpected behavior in dependent picklists.

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 SFX 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.

Models returning fewer results than expected [[]]

When using the Query model action set to Get More - Merge in new rows with old, if the model returns fewer results than expected—and the results diminish with each additional query, until the model is returning no results—the Salesforce StandardSetController may be returning duplicate records, which are not displayed.

The solution is to sort the model. That process adds a unique field (such as Id*, Last Modified Datetime, or Created Datetime) and a sort order (like ASC or DESC) to the model property: Fields to order records by. The addition of a sort, based on a unique value id, ensures that the StandardSetController returns unique records with each load.

Error Messages [[]]

404 Not Found: Could not find a match for URL [[]]

This may indicate that Skuid is not installed in the external Salesforce org. Verify that Skuid is installed in the org you are attempting to connect to.

[object Object] [[]]

This typically indicates an error in querying the Salesforce org. The first configurations to verify are your authentication provider and data source, ensuring that each field matches the necessary values for your external org.

Try recreating the authentication provider—ensuring that the client ID and client secret match the connected app credentials in the external org. If that fails, recreate the data source ensuring that the My Domain is matches the external org.


If working with a sandbox org, ensure that both the instance and sandbox name are included the My Domain portion of your authorize and token endpoints in the authentication provider.

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 end 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 who 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}}.
  5. Click Save.

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