License and Permission Assignments¶
Skuid SFX is a managed package containing custom objects, custom settings, and other metadata for Salesforce. Because of this, all Skuid SFX deployments require you to configure Salesforce sharing rules, permissions, and licenses based on what you want your users to be able to do.
Implementations may vary, but we typically recommend the following checklist:
Set sharing rules for the following objects to Public read only:
- Page
- Page Assignment
For more information on this and potential alternatives, see the Set sharing rules section.
License all Skuid users, whether they view Skuid apps or build them.
For more information, see the License Skuid users section.
Assign permissions based on use case:
- For runtime users: Assign the Skuid Page Viewer permission set and assign Visualforce page access if deploying via Visualforce.
- For builders: Assign the Skuid Page Builder and Skuid Admin permission sets, as well as the following Salesforce permissions:
- Author Apex
- Customize Application
- Manage Certificates
- Modify All Metadata or Modify All Data
For more information on this and potential alternatives, see the Assigning permissions section.
Set sharing rules¶
While permission sets determine object-level access to Skuid’s custom objects, sharing rules determine record-level security. The sharing rules for Skuid’s objects are set to private by default; users can only see records they’ve created. Because of this, end users cannot see any deployed Skuid pages until sharing rules are set.
Additionally since Skuid’s Composer and admin screens are also page records, only Salesforce system administrators can access Skuid’s UI until sharing rules are set.
To resolve this, we recommend setting organization-wide defaults for these objects to Public Read Only for most use cases:
- Page
- Setting sharing rules for this object also grants access to the Page Revision object because of their master-detail relationship.
- Page Assignment
To change these settings in Salesforce Setup:
- Navigate to Security > Sharing Settings.
- In the header of the Organization-Wide Defaults pane, click Edit.
- In the Default Internal Access column, set the following:
- Page: Public Read Only
- Page Assignment: Public Read Only
- Click Save.
Users with permissions to access Skuid’s objects can now see all records, which means they can access Skuid runtime apps (if a viewer) or develop in Skuid’s admin UI and Composer (if a builder). Note that users still must have object-level access through a profile or permission set.
Note
These sharing rules only provide access to Page object records, i.e. the XML used to create Skuid pages. Doing this does not give end users access to other objects in an org at runtime. They do not inherit access to objects queried or referenced in page XML. Skuid automatically respects security settings configured in Salesforce.
Sharing rules to allow for builder collaboration¶
With the sharing rules above, end users can read page data, but builders can only write to records they themselves have created or records shared specifically with them by other builders. Many organizations want to allow for builder collaboration without sharing individual pages.
Granting this write access can happen in variety of ways, and you’ll need to choose the most appropriate based on your org’s needs and security practices:
Alternatives¶
Apex sharing¶
In addition to Salesforce’s UI-based record-level sharing, it’s possible to use Apex to create complex and dynamic sharing rules. This is outside the scope of Skuid’s documentation, but it may be viable for your use case. For more information, see Salesforce’s Understanding Apex Managed Sharing documentation.
Per-page builder permissions¶
If you require more granular permissions (for example, allowing certain builders to only edit certain pages), you’ll need to utilize more advanced sharing rules and related features like user roles.
Remember, Skuid’s Composer and admin interface are also records, so ensure that all builders can access them by setting at least one rule on the Page object. To do this you can use the Module field as criteria, since all pages in Skuid’s managed package are stored in the Skuid
module:
- Navigate to Security > Sharing Settings.
- In the header of the Page Sharing Rules pane, click New.
- Configure the rule’s main properties:
- Label: A recognizable name like Skuid Composer and Admin Access - The Rule name field autopopulates based on the label.
- Rule Type: Based on criteria
- Criteria: Module - equals - Skuid
- Set user access as needed, for example Public Groups: All Internal User or Roles: Skuid builders (if you’ve created a custom role).
- Set Access Level to Read Only—Skuid’s Composer and admin screens cannot be edited.
- Click Save.
If this is the only sharing setting you’ve added, then builders can now access Skuid’s UI, but Skuid pages can now only be accessed by their creators.
You can use Salesforce sharing rules for broader sharing settings, or builders can set sharing details for an individual page from the Composer by clicking the Revisions dropdown menu chevron-small-down > Configure access.
Warning
These sharing rules also apply when pages are deployed. Skuid page viewers must be given read access to the individual page record as well. Otherwise only the builder that built the page can see the deployed page. Consider utilizing page modules alongside detailed sharing rules to ensure end users can access deployed pages.
For example, when a Skuid page is deployed, you could place it in a module named Deployed
and then create a sharing rule to ensure that end users can read records within the Deployed
module.
Note
If a user can still access page records regardless of sharing rules, confirm they do not have View All or Modify All permission on the Page object through another permission set or profile.
License Skuid users¶
Anyone who builds with Skuid or views Skuid apps at runtime must have a Skuid license. Unlicensed users cannot access Skuid in any way.
Assuming you have the Manage Package Licenses Salesforce permission, you can assign licenses in several ways:
Assign Skuid licenses to individuals through Salesforce Setup
If you cannot assign licenses in Lightning experience, you may need to switch to Salesforce Classic.
Mass assign licenses using Salesforce’s Data Loader tool.
Automatically assign / revoke licenses (for Skuid and other managed packages) upon user activation/deactivation through the Skuid’s Licensing / Permissions screen.
Licensing in sandbox orgs¶
Salesforce assigns a site license for Skuid in sandbox orgs by default—meaning assigning individual licenses is not possible.
To accurately test how license assignments could affect your configuration, contact salesops@skuid.com to limit your sandbox licenses to a specific number of users.
License management using a Skuid page¶
If you commonly need to see an overview of active Skuid licenses within your org, consider implementing some of the subscription management tools available in our Sample Pages Github repository.
Assigning permissions¶
Skuid ships with several permission sets. Assign them based on your use case:
- If someone will be viewing your Skuid pages as a runtime user, assign them the Skuid Page Viewer permission set.
- If someone will be building with Skuid in any way, assign them both the Skuid Builder and Skuid Admin permission sets.
Skuid builders also typically need several other Salesforce permissions not included in these permission sets:
- Author Apex: To add and edit JavaScript resources within a Skuid page
- Customize Application: To manage the wide variety of settings, metadata, and static resources utilized by Skuid—like data sources and design systems
- Manage Certificates: To access and edit certificate data necessary to configure some data sources
- Modify Metadata Through Metadata API Functions or Modify All Data: (Optional) To access the module list from the Pages screen (For more information, see the Modules and Metadata API permissions section.)
Skuid builders are typically assigned Salesforce’s default System Administrator profile to obtain these permissions, though they can also be assigned through permission sets.
Assigning Visualforce page access¶
If you’re deploying Skuid using Visualforce pages, you must assign Visualforce page access permissions to end users.
To assign Visualforce page access through a permission set in Salesforce setup:
- From the left-hand menu, select Users > Permission Sets.
- Create a new permission set or click the Permission Set Label of an existing one.
- In the Apps section, click Visualforce Page Access.
- In the Visualforce Page Access header, click Edit.
- For each page used to deploy Skuid, click the page’s name and click Add.
- Once you have selected the Visualforce pages, click Save to save your changes.
- If needed, assign your permission set to end users.
To assign Visualforce page access through a profile in Salesforce setup:
- Navigate to Users > Profiles.
- Click the Profile Name label of the profile you need to assign Visualforce page permissions to.
- In the Enabled Visualforce Page Access section, click Edit.
- For each page used to deploy Skuid, click the page’s name and click Add.
- Once you have selected the Visualforce pages, click Save to save your changes.
Modules and Metadata API permissions¶
Skuid utilizes Salesforce’s metadata API to display available modules on the Pages screen. However the minimum permissions required by Salesforce for a user to query this API are Modify Metadata Through Metadata API Functions or Modify All Data. Without these permissions, builders will see “There was an error retrieving modules” on the Pages screen.
Note that builders can still build in Skuid and assign pages to modules without these permissions. They can also update modules through the Salesforce UI. This permission is only necessary for the modules sidebar in the Pages screen.
For more information, see Salesforce documentation:
Common considerations¶
What if I’m wary of assigning all these permissions?¶
It’s an understandable security concern to grant these powers to builders in a production org. Instead, we encourage builders to work in a sandbox environment where they are fully permissioned. When it’s time to release a Skuid application to a production environment, a designated Salesforce admin and Skuid builder can deploy their app to their production org. This practice ensures builders have the permissions needed to build, but they do not gain unnecessary access to production data and settings.
It’s also worth noting that that as long as a builder has Skuid’s provided permission sets, they can still access some Skuid functionality—like the Composer. However some Skuid features may not function, and unexpected behaviors can occur.
Why assign Skuid permission sets if access is granted through another permission set or profile, like system administrator?¶
When new metadata is added to Skuid’s managed package, its permission sets are updated to allow access as needed. So by assigning builders Skuid’s permission sets, those builders automatically gain necessary access to any new metadata included in an upgrade.
This also ensures builders do not accidentally lose access to Skuid’s objects, settings, and metadata if the non-Skuid permission set or profile changes. For example, while default system administrator profiles are powerful, it may be necessary to create a less permissive clone and assign that to a builder. In that case, the builder may lose access if they do not have Skuid’s permission sets.
What non-Skuid users see¶
The context in which Skuid is deployed determines what happens when an unlicensed user accesses a Skuid page. There are additional considerations if you’ll be using Skuid in Lightning.
In Salesforce Classic and Visualforce tabs, unlicensed users are seamlessly redirected to the standard Salesforce layout for whatever object and action the Skuid page overrides.
In Salesforce Lightning, the deployment method affects the experience:
- Visualforce Page Lightning component: The unlicensed user is redirected to the standard Salesforce layout, which may mean redirecting to a separate tab. This occurs even if other Lightning components are on the page.
- Skuid Page (or Page Assignment) Lightning component: An error appears stating a user must be licensed, and the Lightning page does not load.
Because Skuid can be a smaller part of a larger Lightning page, unexpected redirects and errors may occur if unlicensed users access Skuid in this context. If you’ll be using Skuid in Lightning, be wary of licensing errors.
Auto-licensing and permissioning with Skuid¶
To access Skuid’s license and permission set tools, navigate to Settings > Licensing / Permissions. This screen is made up of several sections, the most important of which allow for auto-assigning and auto-revoking of licenses and permission sets.
There are two primary ways of setting assign / revocation rules for licenses and permission sets in Skuid:
- Whenever a user in your org is created / activated / deactivated (Configured in the Org Defaults section)
- Whenever a user with a specific profile is created / activated / deactivated in your org (Configured as multiple rules in the Profile-specific settings section)
Note
Changes made to a Salesforce user other than creating / activating / deactivating will not trigger Skuid’s auto-licensing or auto-permissioning features.
User Licensing / Permissions¶
This area contains links to Salesforce setup pages that allow you to manually assign Skuid licenses and permission sets.
By visiting these links (or navigating to them through the Salesforce setup UI), you can assign Skuid’s necessary permission sets to single users or to multiple users.
Org Defaults¶
This area contains tools to manage auto-assigning or auto-revoking licenses and permission sets from all new users or all deactivated users.
Package licenses¶
This section allows auto-assignment/revocation of package licenses to users. This can be used for any package license, not just Skuid.
To auto-assign licenses to any user when they are created / activated:
Enable Auto Assign Licenses on Activation.
Click the Packages to Auto-Assign Licenses to setting to pick one or more package licenses to assign.
This means you can auto-assign licenses to Skuid and any other packages listed in the dropdown menu.
To auto-revoke licenses of deactivated users:
Enable Auto Revoke Licenses on Deactivation.
Click the Packages to Auto-Revoke Licenses to setting to pick one or more package licenses to revoke.
This means you can auto-revoke licenses to Skuid and any other packages listed in the dropdown menu.
Permission sets¶
To auto-assign permission sets to any user when they are created / activated:
Enable Auto Assign Perm Sets on Activation.
Click the Permission Sets to Auto-Assign setting to pick one or more permission sets to assign.
This means you can auto-assign Skuid’s own necessary permission sets and any other permission sets listed in the dropdown menu.
To auto-revoke permission sets of deactivated users:
Enable Auto Revoke Perm Sets on Deactivation.
Click the Permission Sets to Auto-Revoke setting to pick one or more permission sets to assign.
This means you can auto-revoke Skuid’s own necessary permission sets and any other permission sets listed in the dropdown menu.
Profile-specific Settings¶
If you want to specify which licenses and permission sets are auto-assigned / revoked to specific profiles, you can do so by adding profile-specific rules in this section.
Once you set up a profile-specific rule, the selected licenses / permission sets are auto-assigned / revoked when any user with that profile is created / activated / deactivated in your org.
Note
It is possible to use profile-specific settings instead of or in addition to org defaults.
To add a profile-specific rule:
Click Add within the Profile-specific settings section.
Start typing the name of the profile, and select it from the list.
Check the boxes of the things you want to be auto-assigned / revoked.
The options available in the modal mirror those described in the Org Defaults section.
Click Add to save the rule.
Assigning permission sets with Apex¶
Anonymous Apex script: Mass Assign the Skuid Page Viewer Permission Set¶
Warning
The scripts below are only examples of how this can be done. We recommend having an admin fluent in Apex modify this script for your org’s needs. And as such, the insert assn
statement must be uncommented for the scripts to take effect.
Using these scripts without understanding their impact could have unintended consequences. Use at your own risk.
Assign a Skuid permission set to all active SFDC / AUL licenses¶
This anonymous Apex script can be run by an admin to help mass assign the Skuid Page Viewer permission set to all active CRM and Salesforce Platform licensed-users who do not already have the permission set. This is done based on license definition key.
Be sure that this is what you want to do before using this script.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | ////////////////////////////////////////////////////////////////
// Assign a Skuid Permission Set to all active SFDC/AUL licenses
////////////////////////////////////////////////////////////////
PermissionSet ps = [SELECT Id, Name FROM PermissionSet WHERE Name = 'Skuid_Page_Viewer' limit 1];
List<PermissionSetAssignment> assn = new List<PermissionSetAssignment>();
List<User> users = [
SELECT Id
FROM User
WHERE Id NOT IN (SELECT AssigneeId FROM PermissionSetAssignment WHERE PermissionSetId = :ps.Id)
AND Profile.UserLicense.LicenseDefinitionKey IN ('AUL', 'SFDC')
AND IsActive = true
LIMIT 10000
];
for (User u : users) {
assn.add(new PermissionSetAssignment(
AssigneeId = u.Id,
PermissionSetId = ps.Id
));
}
//system.assert(false,assn.size());
try {
// insert assn;
system.debug('Permission Sets Assigned => ' + assn.size());
} catch (Exception ex) {
system.assert(false, ex.getMessage());
}
|
Assign a Skuid permission set to all active Skuid licensees¶
The following code assigns the Skuid Page Viewer permission set to all users assigned a Skuid license who do not already have the permission set.
Remember, test and adjust the code to meet your needs.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | //////////////////////////////////////////////////////////////
// Assign a Skuid Permission Set to all active Skuid licensees
//////////////////////////////////////////////////////////////
PermissionSet ps = [SELECT Id, Name FROM PermissionSet WHERE Name = 'Skuid_Page_Viewer' limit 1];
List<PermissionSetAssignment> assn = new List<PermissionSetAssignment>();
String APP_NAMESPACE_PREFIX = 'skuid';
List<User> users = [
SELECT Id
FROM User
WHERE Id NOT IN (SELECT AssigneeId FROM PermissionSetAssignment WHERE PermissionSetId = :ps.Id)
AND Id IN (
SELECT UserId
FROM UserPackageLicense
WHERE PackageLicense.NamespacePrefix = :APP_NAMESPACE_PREFIX
)
AND IsActive = true
LIMIT 10000
];
for (User u : users) {
assn.add(new PermissionSetAssignment(
AssigneeId = u.Id,
PermissionSetId = ps.Id
));
}
//system.assert(false,assn.size());
try {
// insert assn;
system.debug('Permission Sets Assigned => ' + assn.size());
} catch (Exception ex) {
system.assert(false, ex.getMessage());
}
|
Skuid licenses are Skuid subscriptions¶
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.
Troubleshooting¶
Auto-assignment / revocation is not working as expected¶
If you are making user-level changes in Salesforce, yet the license and permission sets stipulated in Skuid’s Org Defaults or Profile-specific Settings are not being assigned or revoked from the user, remember that only user creation, activation, and deactivation will trigger automatic assignment / revocation of license and permission sets.
To make other types of changes to a user in Salesforce and have Skuid to automatically update their licensing or permission sets, consider briefly deactivating and reactivating the user:
- In the User Detail page, deactivate the user.
- Make the changes and Save.
- Reactivate the user with the new settings.
If you need to manually remove or add Skuid licenses, you can do so by following the process outlined by Salesforce for assigning licenses for managed packages. You will also need to manually add and remove the Skuid permission sets for those individuals.
Could not find Skuid Page named “<page name>”¶
When loading a Skuid page in Lightning experience, it’s possible to see this error:
[There was an error rendering a Skuid Page component for page <page name> Error: Could not find Skuid Page named "<page name>"]
This can occur for several reasons:
- The page doesn’t exist: First, check that the Skuid Page (Aura) Lightning component points to an existing page. It’s possible the specified page may have been renamed or deleted. If so, update the Lightning component to put to an existing page.
- The user doesn’t have a Skuid license: It’s possible for this error to display when the user is missing a Skuid license, though a license-specific error typically displays. Verify that the user has a Skuid license.
- The user doesn’t have permission to access the page: If the page exists and the user has a license, then it’s possible the user does not have the permissions to view the page—either at the object level or the record level. Verify that the user has the Skuid Page Viewer permission set for object-level access and that sharing rules have been properly set for record-level access.
Common sharing rule errors¶
The following errors can occur at runtime or in Skuid’s admin screens when sharing rules disallow a user from seeing a Skuid page record:
We couldn't load the page you were looking for. You may not have permission to see this page, or it may no longer exist. Ask your system administrator if you have access to the Page object or if this page has been deleted.
Data Not Available The data you were trying to access could not be found. It may be due to another user deleting the data or a system error. If you know the data is not deleted but cannot access it, please look at our support page.
- In Lightning, my runtime users have an endless spinning loading icon.
Even if a user is licensed and permissioned, it’s possible to see errors if the sharing rules for Skuid’s objects are not configured to allow that user access. In the case of an endlessly spinning loading icon, an end user may have previously had access to a Skuid page but lost access through a sharing rule or permission change.
Confirm sharing rules on the Page and Page Assignment objects are set up to Public Read Only. If you are using an alternative sharing rule setup, verify it grants the proper record access to the necessary users. For more information see the Set sharing rules section.
If you’re a Skuid builder, you may not have write access to page records besides your own if you see errors like the following:
insufficient access rights on object id
[{"statusCode":200,"type":"rpc","tid":35,"ref":false,"action":"skuid.RemotingStubs","method":"save","result":{"deleteResults":[],"globalErrors":[],"insertResults":[],"updateResults":[{"errors":[{"fields":[],"message":"insufficient access rights on object id","severity":"ERROR","status":"INSUFFICIENT_ACCESS_OR_READONLY"}],"id":"<recordId>","messages":[],"source":"page","success":false}]}}]
Consider adjusting sharing rules to allow for builder collaboration based on your organization’s needs.
Note it may take time for sharing rule updates to propagate. If you’ve updated your rules but are still seeing errors, try again in a few minutes.
Common licensing errors¶
The following errors indicate a user may not be granted Skuid managed package license:
License Required: The Visualforce Page PageList is part of the AppExchange Package Skuid, and requires a license to use. For more information, see Insufficient Privileges Errors.
[There was an error rendering a Skuid Page component for page <page name> Error message: The Visualforce Page VFSessionId is part of the AppExchange Package Skuid, and requires a license to use.]
Insufficient Privileges You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary. For more information, see Insufficient Privileges Errors.
If a user sees any of the above errors, ensure they have been assigned a Skuid license.
Common permission set errors¶
The following errors indicate a user may not have the necessary permissions:
Insufficient Privileges You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary. For more information, see Insufficient Privileges Errors.
Potential solution: Ensure the runtime user has been granted the Skuid Page Viewer permission set. If the user is trying to access a page that uses a Visualforce override, grant access to that specific Visualforce page.
There was an error performing this query: sObject type 'Certificate' is not supported.
Potential solution: This error occurs when a builder accesses the Data sources screen without the Manage Certificates Salesforce permission. If possible, grant this permission to the builder seeing the error.
You do not have permission to create or modify pages that contain JavaScript resources. This requires the "Author Apex" permission.
Potential solution: This error can occur when a builder attempts to edit pages containing JavaScript resources without the Author Apex permission.
If this builder should be able to edit these resources (and the other powers granted by the permission), grant Author Apex to the builder seeing the error—either through a permission set or profile. Otherwise the builder cannot save any changes to the page until all JavaScript resources are removed.
[There was an error rendering a Skuid Page component for page <page name> Error: Could not find Skuid Page named "<page name>"]
Potential solution: Ensure the runtime user has been granted the Skuid Page Viewer permission set. If the user is trying to access a page that uses a Visualforce override, grant access to that specific Visualforce page.
I see many errors listed on the data sources or design systems screen:
A Skuid Model, 'AvailableDesignSystems', requested a Field with relationship name 'LastModifiedDate', on the skuid_Theme_c Object, but Skuid could not find a valid Field accessible through this relationship name.
A Skuid Model, 'stng_ModelDataSources', requested a Field with relationship name 'LastModifiedDate', on the skuid_Theme_c Object, but Skuid could not find a valid Field accessible through this relationship name.
A Skuid Model, 'stng_AuthProviders', requested a Field with relationship name 'LastModifiedDate', on the skuid_Theme_c Object, but Skuid could not find a valid Field accessible through this relationship name.
A Skuid Model, 'stng_DataServices', requested a Field with relationship name 'LastModifiedDate', on the skuid_Theme_c Object, but Skuid could not find a valid Field accessible through this relationship name.
Potential solution: The following errors (and more like these) can occur in the admin UI if a builder is not assigned the Customize Application permission.
SObject row was retrieved via SOQL without querying the requested field: skuid__Page__c.skuid__MasterPage__r An unexpected error has occurred. Your solution provider has been notified.
Potential solution: This often shows if a user does not have the Skuid Page Viewer permission set. If a builder sees this message, verify they have the Skuid Page Viewer permission set assigned to them.
I see the errors like the following when accessing the Composer:
A Skuid Model, 'page', requested a Field with relationship name ...
A Skuid Model, 'pageBuilder_SelectedVersion', requested a Field with relationship name ...
A Skuid Model, 'pgs__NewPage', requested a Field with relationship name ...
A Skuid Model, 'versions', requested a Field with relationship name ...
A Skuid Model, 'ClonePageData', requested a Field with relationship name ...
Potential solution: This indicates a builder does not have access to the fields used in Skuid’s admin screens. If a builder sees error messages similar to the shortened examples below, verify they have the Skuid Page Builder permission set assigned to them.
In Lightning, my runtime users have an endless spinning loading icon.
Potential solution: The end user may have previously had access to a Skuid page but lost access through a sharing rule or permission change. Verify they have record-level access through sharing rules, that they have the Skuid Page Viewer permission set, and that they have access to any necessary Visualforce pages.
Apex triggers not working as expected¶
Due to Salesforce restrictions regarding setup object operations, Skuid’s triggers may not function well in combination with other user-creation triggers. If Skuid’s triggers and your triggers are grouped as a single transaction, you may see unexpected behaviors or your licenses and permissions may not assign properly.
If you have existing user-creation triggers, or wish to implement additional triggers, consider one of the following alternatives:
- If you “own the code” for the additional triggers, consider placing setup object DML statements within future methods to ensure that they run within a separate transaction.
- If you do not wish to use future methods, consider writing your own auto-licensing and permission granting functionality into new or existing functions. This will give you greater control over how and when licenses are assigned and will reduce the likelihood of undesired results.
Licenses aren’t working in a sandbox org¶
Sandbox orgs are granted site licenses, meaning individual licenses are not assignable. You’ll need to contact Skuid to limit licenses in this scenario. Related resources =================