🔐 Managing Query Use in Slate

One of the features that tends to excites institutions new to Slate is the ability for staff to have access to the data Slate collects. Shortly after launch, one of the main headaches for Slate captains is dealing with users who now have access to the data Slate collects. Despite comprehensive training sessions and extensive documentation, individuals may either seek access to data  they shouldn't have or make mistakes that have them walking over to your desk to say Slate isn't working. To foster a positive user experience and streamline operations, we've compiled the following strategies for managing queries in Slate. 

1. Help users only see records relevant to them by building queries on population-aware configurable join query bases. You can link to these queries in homepage widgets, dashboards, or in portals. These will be the starting point for your users and won't require anyone to remember to add a filter to narrow down their results to the appropriate population. Details are available in the Managing Record Access in Query Using Population Permissions Knowledge Base article.

2. Make Slate aware of your institution's definitions for commonly queried datapoints. Your users may want to query on this year's admitted students, but what counts as an admit? Should that include people who later declined your offer? What about people who deferred from last year? Take the time to build out query library exports and filters so your users are all working from the same definition and no one complains that the numbers in Slate aren't matching up. Technolutions has even provided a foundation to work from with their Commonly Used Person-Scoped Exports and Filters and Commonly Used Application-Scoped Exports and Filters.

3. Monitor newly-built queries. If you've granted users the capability to create their own queries, it's prudent to keep an eye on their query construction. You can do this via configurable joins by building a query on the 'Configurable Joins - Query' base. You could filter on queries with a created date of today - 1 in order to see all queries built the day before. From there, add relevant exports about the query itself and a subquery export joined to the user so I could see who had built the query. What you do with this information is up to you. You may find otherwise empty queries named something like "Current History Admits." You could build the query on the user's behalf because the query name makes it pretty clear what they're looking for. Alternatively, you could reach out to the user who built the query with your institution's user guide for query building and/or inform them of upcoming query training. Letting users know that the queries they build have an impact on the system and that someone is there to help can make a big impact. A sample query is available via this suitcase id: ad7b2bda-6b0d-4318-81a6-734a3b57e393:rwf-test

Unsure what to do with old/unused queries? Read our article: Why Archive Queries.