Testing New Dashboard Recipes
Last Updated:
The PocketPlatform Dashboard is an awesome tool that can really help you engage with your congregation in many ways. We have provided a significant number of in-app routing options to help your users navigate the app from the dashboard, and we’ve designed it to be easily editable using SQL, which gives you the power to use any information in MinistryPlatform to generate your recipes.
But you need to test those recipes before you make them live to your whole congregation! We’ve put together a quick primer on how to configure a recipe in a testing environment before you make it live to everyone.
Please Note: Any time you are altering the dashboard, it’s possible to create a situation where the dashboard may fail to load. As such, it’s advisable that you make a backup of the existing SQL before you start working on a new recipe, and always test the dashboard before considering your task complete!
Creating a testing block
Please Note: The content in this Knowledgebase Article assumes that you have good working understanding of SQL and are comfortable editing SQL inside the tools provided by Microsoft. If you need additional assistance or instruction on either of these topics, you can find detailed tutorials at codecademy, w3schools, and Microsoft’s own documentation.
Since the PocketPlatform Dashboard leverages the content and data inside MinistryPlatform, you have a lot of flexibility when designing dashboard recipes to target users within different demographics. For example, you can use your MP data to write a recipe that could present an invitation to Women over the Age of 35.
(In order to avoid exposing internal database structure, the actual query that would be used to identify demographic information will not be shared here. Please refer to the actual database schema to build your demographic data.)
(Your dashboard may already contain a query that determines demographic data. If that is the case, feel free to use those demographic variables instead of generating new ones.)
The basic structure of a testing block is as follows:
- Conditional statement that specifies the user IDs that should see this testing block
- Optional overrides for specific demographic data
- The actual dashboard recipe
IF @UserID IN (123, 456, 789) -- The user IDs that can see this recipe right now BEGIN --Overrides for user demographic conditionals. SET @UserGenderID = 2; SET @UserAge = 36; -- Actual recipe starts here /* =========================== == Show to women over 35 =========================== */ IF (@UserGenderID = 2 AND @UserAge > 35) BEGIN INSERT INTO @Items EXEC [dbo].[my_custom_sproc] @DomainID = @DomainID ,@OtherValues = @AsNecessary END -- == E == END
Once the recipe is working as you expect and the dashboard is displaying properly, you can enable this new recipe for your users.
To do so, simply remove the UserID restrictions, as well as any Variable Overrides you may have added. For our example code, that would look like this:
/* =========================== == Show to women over 35 =========================== */ IF (@UserGenderID = 2 AND @UserAge > 35) BEGIN INSERT INTO @Items EXEC [dbo].[my_custom_sproc] @DomainID = @DomainID ,@OtherValues = @AsNecessary END -- == E ==
Good To Know
- We’ve created this testing process to cause as little disruption to your users as possible. If the SQL code is broken or malformed, MSSQL won’t update the Stored Procedure, and if the logic is incorrect or causes an error elsewhere, if won’t prevent the dashboard from loading for users that aren’t in the Included Users List.
- Please be sure to remove any override variables before activating the new recipe.
- ALWAYS back up your stored procedure before editing.
- You may want to consider keeping a “testing section” in your dashboard at all times that would allow you to move testing recipes in and out of a set userbase.
- Remember to move the recipe out of testing when you’re done!