FAQ
I have two list views on the page to allow for filtering. But when I select records from one the other does not filter based on the selection!
I refreshed my sandbox and now get the following error - "Global config not found. Go to the admin page and either import a config file or create a new config."
Report it here on github.
They can all be found on the appexchange page which is here - Simpli List Views AppExchange Page. Scroll to the bottom section called "Customization Guides".
They can also be found on the Start page once the app has been installed - https://<ORG_URL>/lightning/n/simpli_lv__List_Views_Start
Simpli List Views has enhanced debugging capabilities to allow for quicker help and resolution if persistent problems are found. Many of the debugging logs are technically detailed and will only make sense to the developer of SLV. To turn on debugging go to the admin page and set the "Debug" parameter value to true.
Note - when debugging is turned on large amounts of data will be saved. This may reduce performance as well as use up a lot of data space. It is advised to turn debugging on for short periods of time just to capture the data that is needed.
Once debugging has been turned on the action can be performed which is causing problems. The debugging logs can then be viewed by going to the "List View Logs" tab in the SLV Admin app.
Since the app is built by one person the decision was made to create videos instead of documentation. Documentation takes a lot of time to create and once created needs to be constantly revised. This would take away from adding new features! The documentation that has been created includes this FAQ page and the start page on the app which contains valuable information regarding configuration options and actions and adding extension actions.
Note that there is a developer example tab which provides dev examples as well as descriptions of those examples and how to code for them.
The following are profile settings which give access to all functionality for a profile.
Note that these settings will change depending on the functionality you allow for the users -
- To allow users to refresh/update the list view data they will need edit permission for the List Views custom object.
- To allow users to make changes to the page admin via the cog icon they will need modify all permission for the List View Config, List View Config Conditions and List View Config Parameters custom tables
Also, the users should not be given access to the custom object tabs themselves. Any administrative work or data fixes that need to be made should be done by an administrator.
List view access is based on a number of different Salesforce settings. They are checked in the following precedence and if any one of them is TRUE the list view is displayed -
-
Can the user see the list view? (This can be determined by opening the dev console as the user, running the following query and seeing results) -
SELECT Id FROM ListView WHERE Name = 'LIST VIEW NAME GOES HERE' -
Does current user profile have "Modify All Data" permissions?
-
Does the current user OWN the list view?
-
Is the current user in one of the GROUPS allowed by the list view?
-
Is the current user in one of the ROLES allowed by the list view?
-
Is the current user in one of the ROLES OR SUBORDINATES allowed by the list view?
-
Is the current user in one of the TERRITORIES allowed by the list view? (still to be implemented)
See the below image showing the fields which permissions get verified against on the list view. This data is pulled in from the core list view information.
NOTE - if security on the core list view is changed then Simpli List View data must be refreshed for that list view.
- Have the list views been refreshed? If any core setting changes, including security, the list view must be refreshed.
- Does the object have core list views? If not then the object name will not be displayed.
Yes. If the auto refresh button has been made available through admin config (defaulted to available) then users can auto refresh list views.
Yes, you can for core list views. Once the list view is open add fields by going to the admin cog dialog (far right button) and then add the API field names into the "Additional Fields" setting.
Core list views are always created through the standard Salesforce list view creation process. Simpli List Views then uses that data to display the list views again in the Simpli List View app. These list views are limited to what Salesforce allows the user to do.
Custom list views are created through the Simpli List Views app by adding a record in the List View table. From a data perspective these list views are only restricted by the SOQL query the user creates. Actions are not current available for custom list views. Inline editing is available although only for the header record fields.
Yes. A custom list view will need to be created for this.
Multi-column sorting is configured to work out of the box. But if sorting is not working the following should be checked -
- Users must have create, edit and delete permissions for the List View User Config custom object.
- If you have a page with an SLV component dragged on to the page then check the components config. Specifically the "Do Not Allow Sorting" checkbox should NOT be checked.
- Ensure the global admin setting allows sorting. This config setting should be set to "No".
To ensure that sorting gets saved and defaulted your user must have create, edit and delete permissions for the List View User Config custom object.
Standard list views are visible to all users except in cases where the sharing settings have been altered. This same approach is applied to custom list views. So, in order to add sharing settings to a custom list view the groups, roles and territories must be added to the list view config, similar to the example below.
Note that all group, role and territory names provided are the developer or API names.
- Edit Action – this is only for a single record. It allows you to edit a single record and shows the existing data.
- Update Action – this is for one or multiple records. It is used to update a configured number of fields. It is for mass update of records with specific values.
- Edit All Action – this action uses the inline editing feature for each record. It sets all records inline editing on and allows the user to update those fields and records that they want that are allowed to be updated. Although all records are set to inline editing single or all records can be saved at a time.
- Single Record Inline Edit – this is not an action. If inline editing is enabled and you double click on a record it will become available to be edited and saved.
Note the following -
- for inline editing only fields that are editable by the user based on permissions are available to be edited.
- when using the Edit All Action individual records can be saved. It is not necessary that all records be saved at the same time.
I have two list views on the page to allow for filtering. But when I select records from one the other does not filter based on the selection!
Check the following -
- For the SLV component that will be filtering its records make sure the "Use Message Channel" checkbox is checked.
- Make sure the "Joined Field Name" is set on the SLV component that will be filtering its records and is correct. This value must be the API field name for the records in the SLV component that hold the Id values of the records being checked from the first SLV component.
For example - if the first SLV component holds Accounts and the second SLV component holds Contacts the "Joined Field Name would be "AccountId" since that is the API field name on the Contact that would be used to filter on the selected Accounts.
Salesforce only returns a maximum of 200 records in a list view and after that the user must page through the data. Also, there are only a set number of columns that Salesforce allows to be displayed in a list view. These limits are there for good reason. We work in a multi-tenant environment! But, depending on business process these limits can be frustrating. SLV was partly created to resolve these limits.
Timeouts typically happen for a couple of reasons -
- The number of columns in the list view plays a big part in how long the data takes to load. Try to ensure that only those columns that are necessary for the user to make decisions are displayed. Typically no more than 10 or 12 should be displayed.
- The number of records returned at one time also has a big influence on how long the data takes to load. The number of rows returned at one time should preferably not be more than a few hundred.
With that said, here are some general guidelines to try and resolve these issues -
- Reduce the columns being displayed if possible. Column reduction will greatly improve performance.
- Reduce the number of records that are returned for the list view. There are two ways that this can be set.
List View Config - users are able to set the return size of the records in the list view config
Admin Page - sys admins can set the org wide max return size of the records in the admin page.
- Another option is to utilize the paging mechanism that is built into SLV. This allows a larger number of records to be displayed in the list views by handling the records in batches. To use this method a sys admin must appropriately set the Query Paging Size in the admin page. For example, if the Max Rows Displayed is set to 800 and the Query Paging Size is set to 50 then a list view would be able to display a maximum of 800 rows in the list view but the data would be returned in batches of 50, thus taking 16 round trips to return all data.
Actions are displayed for a list view based on a number of criteria. The criteria include -
- Actions are paired with the kind of list view. Actions with record type Core are only available for core list views. Actions with record type Custom are only available for custom list views.
- If an object type is set on the action the action will only be available for list views that have that same object type.
- If the action is of record type Custom then the subtype of the action must be set. This subtype must match the subtype of the list view being displayed.
- If the action has Permissions set on it then the user must have those permissions for the object type in order to see the action.
- If the action has a component name set on it then the action will only be displayed on that LWC component.
- The action must be active for it to be displayed.
The following image shows the fields which are critical to identifying whether the action will be available for a list view -
There could be any number of reasons why SLV hits governor limits. The following are things to check before submitting an issue -
- Email threshold reached - sometimes the thresholds set by Salesforce to send an email are breached by SLV. This does not mean anything is wrong. An example of this is when initializing or refreshing the list views. These emails should not occur much other than during initialization of the list views.
- Too much list view data - this sometimes happens when the list view is too wide (too many columns) with too many rows being returned. The only option here is to reduce the amount of data being returned by either returning fewer rows or reducing the number of columns.
- Org usage already high - this sometimes happens if the org is already being used extensively and then SLV is installed and initialized. When SLV first initializes it uses 2 x list view count of API requests. So for example if the org has 800 core list views at initialization it will perform 1600 API requests. To check the current system API usage go to Setup -> System Overview. See screenshot below
The admin export function allows admins to move config from one org to another. This is especially useful when a developer sandbox is created which has no data. The following data gets added to the export file -
- Custom List Views - all custom list views. This includes custom list views of subtype Manual as well as Tooling. Core list views do not get copied over as a refresh will accomplish the same thing.
- Custom List View Configs - all configuration for the custom list views added above are also added. This includes all config parameters and highlighting conditions.
- All Actions - all actions are added. This includes all core actions as these may have been customized. All action parameters are also included.
When importing data, once the import is complete some basic results are displayed to the user to give them an indication as to what processing took place. The results are displayed as follows -
The above results shows the following occurred -
- List Views - 11 upserted and 0 errors
- List View Configs - 12 upsrted and 0 errors
- Actions - 2 upserted and 17 errors
Note that importing will update a record if its detected that it already exists in the org. If the record cannot be found an insertion will occur.
For those records that errored there could be a number of reasons. The best way to start identifying what the issue is would be to ensure debugging is turned on
Yes, a custom export file can be created although customization of the file is not supported. If customizing, the file must follow the exact JSON format of the export file. What is suggested is to create an export file and then use that as a template for any changes. The following customizations can be performed on the export file -
- New list views, configs and actions can be created. The exact fields must be filled in as what is provided in the export file. Also, for all entities the simpli_lv__Primary_Key__c field must be unique. This will ensure the entity is created and not updated.
- List views, configs and actions can be cloned. This can be done by copying the entity to be cloned and then updating those fields to be changed. Be sure to update the simpli_lv__Primary_Key__c field on the entity to make sure its unique.
There are a few cases where inline editing is not possible. These include -
- Formula fields.
- Geolocation fields.
- Rich text fields.
- Fields not associated directly with the object. Most of these cases involve fields on a child or lookup object. The rule of thumb is that only fields directly on the object that the list view is associated with will be available for inline editing.
Here are field examples that are and are not allowed -
- For a list view based off an account - Name - allowed
- For a list view based off an account - Contact.Name - not allowed
- For a custom list view based off an opportunity - CloseDate - allowed
- For a custom list view based off an opportunity with line item children - Opportunity.OpportunityLineItem.Quantity - not allowed
Note that this also applies to any field that is added as an additional field to the list view via its admin settings.
Other cases where inline editing is not available include fields that are of type formula, geolocation and rich text fields.
Custom list views can use the filtering capability except those custom list views that have related children returned.
So for example –
- This will allow text filtering –
SELECT Name, Status, Type, Phone FROM CampaignMember
- This will NOT –
SELECT Name, StageName, CloseDate, ExpectedRevenue, simpli_lv__TrackingNumber__c, Account.Type, Account.Industry, Pricebook2.Name, PriceBook2.IsActive, (SELECT Name, ListPrice, Product2.Name, Product2.ProductCode, Product2.LastModifiedBy.Name, Quantity, TotalPrice FROM OpportunityLineItems) FROM Opportunity WHERE HasOpportunityLineItem = true AND IsWon = false
The reason is that text filtering uses SOSL and SOSL does not support related children in the query.
I refreshed my sandbox and now get the following error - Global config not found. Go to the admin page and either import a config file or create a new config.
If you are getting an error similar to this screenshot then chances are you have refreshed a sandbox and SLV can no longer find the config it needs to operate.
To resolve this issue either go to the admin page and click the Create button in the Import/Export section -
or go to another org that holds the configuration and click the export button then go back to the broken org and import the configuration -
If for some reason the admin page is not accessible then do the following -
- As a sys admin go into settings and clear the cache. Settings -> Platform Cache -> SimpliListViewsCache -> Clear Cache.
- Look at the records you have in Simpli List Views Admin (app) -> List View Config Parameters (tab) -> All:All List View
You should be seeing the following config parameters with values approximating the below –
If you are missing any then add a new one manually. You should be able to look at your PROD org and copy them over. Make sure the List View Config parent each new parameter is associated with is the correct one. Should be one that looks like this -
Once the config parameters have been created see if you can access the admin page and refresh the list views.
Both core and custom list views can be cloned. Do the following steps to clone a list view.
- Go to the Simpli List Views Admin app and click on the List Views tab.
- Find the list view that you would like to clone. For example -
- When cloning remove all data in the following fields – ListView Id, Primary Key, Describe. Those fields will be repopulated as necessary or are not needed. Save the record.
- Now that the record is saved change the following fields -
- Record type to Custom.
- Custom Apex Class to ListViewCustomManual.
- Subtype to Manual Save again.
- Make sure your list view is working by checking using the Simpli List Views Example app and the Everything Example tab. Select the list view to be sure.
- Now that the list view works we want to make changes to it by updating the following fields -
- ListView Query - update the query with the SOQL that you intend to use.
- ListView Columns - update this field with a JSON representation of the columns in your SOQL. Look at other custom list views to get an idea for what is needed.
- Save and retest. Your custom list view is now available for users.