Salesforce

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 are using Skuid SFX 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 https://acmesales-dev-ed.my.salesforce.com/. 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, https://acmeaccounts-dev-ed.my.salesforce.com), 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.

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.

Before you start

  • You must have the latest version of Skuid installed in each external Salesforce org you will be accessing.
    • You do not need to have Skuid licenses or permission sets assigned in the external org, though you must have them assigned in the connecting org.
  • My Domain must be enabled on any Salesforce org you will be accessing. Production orgs created in for Salesforce’s Winter ‘21 release or later will have this enabled by default, but be sure your My Domain is set to a name that is unlikely to change. Anytime an org’s My Domain is updated, you must update any Skuid data sources with that information as well.

    While the org’s instance-based URL (e.g. https://na30.salesforce.com/) 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 in Classic or Company Settings > My Domain in Lightning. 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.

Warning

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

Configuration

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.

Note

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:

    • Classic: Navigate to Build > Create > Apps. Under Connected Apps, click New.
    • Lightning: Navigate to Apps > App Manager. Click New Connected App
  2. In the New Connected App page, enter the app’s basic information:

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

    Note

    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:

      • Manage user data via APIs (api): This scope allows users to access and make changes to Salesforce records within the Skuid runtime.
      • Perform requests at any time (refresh_token, offline_access): This scope grants Skuid access to a refresh token–which means Skuid can request additional access tokens without requiring the user log back in. In effect, this means users typically only have to log in through this OAuth flow once.

        Access token expiration is determined by the org’s session security policy, while refresh token expiration is determined by the Refresh Token Policy in the connected app.

        For most Skuid implementations, the Refresh token is valid until revoked policy enables the smoothest login experience, but adjust the policy based on your org’s security needs. For more information on refresh token policy options, see Salesforce documentation.

  4. Click Save.

Note

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:

When using Skuid SFX, 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.

Note

Lightning Experience requires that My Domain be enabled.

There are also different URLs needed based on whether the Skuid page is deployed using the Redirect, the skuid:page Visualforce component override method, or the Skuid Page (Aura) Lightning component. Because of this, it’s best to enter all callback URLs for Skuid SFX orgs within your OAuth applications.

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

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. Navigate to the connected app: - Classic: Navigate to Manage Apps > Connected Apps. Click the master label of the connected app - Lightning: Navigate to Apps > App Manager. Beside the app you just created, click the More options down arrow > Manage.
  2. Click Edit Policies.
  3. 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.

      Note

      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

      Note

      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 to the connected app: - Classic: Navigate to Create > Apps. Click Manage beside the connected app - Lightning: Navigate to Apps > App Manager. Beside the app you just created, click the More options down arrow > Manage.
      2. Click Manage Profiles in the Profiles pane.
      3. Select which profiles should have connected app access.
      4. 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.

Credentials

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

  1. In your external Salesforce org, from the Salesforce Setup pane:
    • Classic: Navigate to Build > Create > Apps. Under Connected Apps, click the app you just created.
    • Lightning: Navigate to Apps > App Manager. Beside the app you just created, click the More options down arrow > View.
  2. Under API (Enable OAuth Settings), find:
    • The consumer key
    • The consumer secret (click to reveal)

In Skuid site

With the connected app set up 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.

Note

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.

Note

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.

Note

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:
  • https://externalorg-dev-ed.my.salesforce.com/services/oauth2/authorize
  • https://externalorg-dev-ed.my.salesforce.com/services/oauth2/token
  • Default Scopes: If not auto-populated, insert the following:
  • api,refresh_token,offline_access

    Note

    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.

Note

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.

Note

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.

Enable metadata caching

  1. Navigate to Data Sources.
  2. Click the row item for the Salesforce data source you wish to cache metadata for.
  3. Within the data source’s detail page, click Enable Metadata Cache.

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

Refresh the metadata cache

Skuid cannot detect that a data source’s metadata has changed, such as when a new field is created, so Skuid will not automatically refresh the cached 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 Data Sources.
  2. Click the row item for the cached data source.
  3. Click Refresh Metadata.

Doing this will cause Skuid to re-download the metadata the next time a user accesses a page using that data source in a model, grabbing the most recent updates in the process.

Disable metadata caching

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

  1. Navigate to Data Sources.
  2. Click the row item for the cached data source.
  3. Click Disable metadata cache.

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

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.

Note

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.

Note

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.

Note

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.

Note

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.

    Note

    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

Warning

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

  • Apex: Invokes Apex methods within Skuid.

    Note

    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.

  • Clone: Clone the selected record to a designated model.

  • Share: Share the selected record with a designated model.

  • SFDC Web Link: Name and add a custom link to a Salesforce Object.

Approval Process actions

Note

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

    Note

    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.

    Warning

    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.

Note

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 Force.com 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.

Note

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 Force.com REST API Developer Guide Invocable Actions and Introducing Actions sections, or review the Force.com Actions Developer Guide.

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

Salesforce API Usage

Skuid SFX 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. Any use of Salesforce data source actions will consume an API Call.

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

    Note

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

Accessing an external org’s data—whether through model queries or Salesforce data source actionswill consume API calls in the external org.

Troubleshooting

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.

Known limitations for Salesforce’s PriceBook2 object [[]]

Skuid strictly follows Salesforce’s security model, even known limitations . For example, model queries of the PriceBook2 object will return all PriceBook records, not just the end user’s.

Model conditions and query limits still apply, but the PriceBook2 object ignores sharing rules when queried. The end user may see PriceBooks that were not assigned to them.

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:

error=redirect_uri_mismatch&error_description=redirect_uri%20must%20match%20configuration

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 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 …

OAUTH_APPROVAL_ERROR_GENERICT

… 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, try adding the Full access (full) scope to both the external org’s connected app and the Skuid site’s authentication provider. This scope provides more permissions, making it helpful for debugging. However, if this level of permissioning is not appropriate for your implementation, you can remove it after debugging the connection.

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">
      <script>
      window.skuid = {
        platform: {
          getOAuthProxyUri: function(){
           return window.location.origin+(window.$A?'/skuid/oauthproxy.app':'/apex/ skuid__oauthproxy');
          }
        }
      };
      </script>
        <script src="{!URLFOR($Resource.skuid__JqueryJS)}"></script>
        <script src="{!URLFOR($Resource.skuid__OAuthClientJS)}"></script>
        You have been successfully authenticated! This window should close momentarily...
    </apex:page>
    
  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.

Note

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

or

invalid_grant

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 the connected app list: - Classic: Navigate to Build > Create > Apps. Click Manage beside the connected app. - Lightning: Navigate to Apps > App Manager. Beside the app you just created, click the More options down arrow > Manage.
  2. Click Edit Policies.
  3. Set IP Relaxation field to Relax IP restrictions or Relax IP restrictions with second factor.
  4. 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 …

error=invalid_client_id&error_description=client%20identifier%20invalid

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.

TypeError: Cannot read property 'indexOf' of undefined when trying to set a model object [[]]

Verify that the data source has an authentication provider set in the data source’s Authentication tab. If necessary, recreate the authentication provider in the Data Sources > Authentication providers tab and set the data source to the recreated authentication provider.

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.