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

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.

Note

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

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, 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:

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

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:

Skuid Platform [[]]

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

Some examples:

  • For https://example-us-trial.skuidsite.com/, use https://example-us-trial.skuidsite.com/auth/oauth/callback
  • For https://gui-construction.skuidsite.com/, use https://gui-construction.skuidsite.com/auth/oauth/callback
  • For https://asgard-talent-management.skuidsite.com/, use https://asgard-talent-management.skuidsite.com/auth/oauth/callback

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:

Note

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:

https://customMyDomain-dev-ed--skuid.na30.visual.force.com/apex/PageList

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>--skuid.visualforce.com/apex/skuid__oauthcallback
  • https://<myDomain>--c.visualforce.com/apex/oauthcallback

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

  • https://<myDomain>--skuid.<Instance>.visual.force.com/apex/skuid__oauthcallback
  • https://<myDomain>--c.<Instance>. visual.force.com/apex/oauthcallback

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

  • https://skuid.<Instance>.visual.force.com/apex/skuid__oauthcallback
  • https://c.<Instance>.visual.force.com/apex/oauthcallback

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.

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

Credentials

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.

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

Note

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

Note

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

Note

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.

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:

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

      Note

      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.

    • 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, users can upload the files into the Files list.

While these changes will impact Salesforce Lightning Experience 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. However, Skuid does not support Advanced Currency Management.

Warning

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

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

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.

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

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

Note

Only authenticated Salesforce 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.

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

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.

    Note

    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.

Troubleshooting

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

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, 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">
      <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.

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

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.

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.