From JMP to JMP Live: Deploying Automated Analytics Workflows (2026-US-30MP-2954)

Welcome to our talk, From JMP to JMP Live: Deploying Automated Analytics Workflows. My name is Wendy, and I'm joined by my colleague Monique. Luiza will also be presenting live in Baltimore, but I will be recording her presentation today.

This talk came about through conversations with scientists and engineers who have built automated workflows in JMP to pull, prepare, and analyze data and are interested in extending those workflows into JMP Live. Along the way, we saw an opportunity to create a practical, step-by-step resource to help users make that transition more easily. Today, we'll highlight a few examples that showcase the types of workflows we'll be documenting in the JMP Community, providing a practical resource that users can reference and build on over time.

I will kick us off by talking about adapting JMP Query Builder workflows to JMP Live, and then I'll pass it to my colleague Monique to take the second example.

In JMP, there are a few common approaches people take to automate workflows. In this talk, we will focus on a workflow automated using Query Builder. You can go to the community resource and see content related to Workflow Builder.

There are many different data sources that people are connecting to in JMP in these automated workflows. In this talk, I will focus on a workflow that connects to a database. Again, the community resource will reflect other examples related to other data sources.

Let's say you're a JMP user, your organization has recently purchased JMP Live, and this has enabled you to share reports like this stability trending report with others in your organization, whether they have JMP or not. The data behind this report comes from a database and requires some data preparation to enable the report. You have automated this already in JMP with Query Builder. Now you want to automate this in JMP Live. This is the perfect use case for JMP Live, but how do we go about making this happen exactly?

Before we get to specific examples, we're going to take a step back and talk about the JMP Live report anatomy, so to speak. When you publish a report to JMP Live, there are two objects related to that report. The first object, well, simply is the report itself. Then there's a second object, which is the data table that drives the report. Let's take a closer look at the report itself. When you publish a report to JMP Live, the script, or the JSL, that creates the report is automatically included in the report script. You'll see me reference the report script using this little scroll icon with an R in it.

The data table has settings that you can modify. In those settings, an option is to refresh the data using a script. Here you can see the option is selected Refresh Data via Script, and this empty space here is where you can put JSL or Python instructions for refreshing the data. These instructions can include information both about getting the data itself, and it can include instructions around data preparation. Then, of course, we can set a schedule for that refresh to occur on a regular basis automatically.

A quick recap. We have the report itself and the data table when we publish a report to JMP Live. The report has a script that creates the report, and the data table has an option of having a refresh script if we want the data to update automatically. The report script gets uploaded automatically, and there's nothing for us to do there. The data table has an option for a data refresh that we need to modify if we want to automate data refreshes. The good news is, sometimes it can be as simple as indicating that we want to use the source script that is populated automatically in JMP Live.

Let's get to the examples. Today, we're going to walk through two examples of adapting Query Builder workflows from JMP to JMP Live, and we'll build from a simple example. The first example is simple in that there is no data preparation needed before creating our report. Our workflow in JMP involves pulling data from the database using Query Builder, and then directly from that source data, we create the report that we want.

When we publish the report to JMP Live, remember, there are two objects involved. There's the report itself and the data table that the report is based on, each one with their own scripts. If we want the report to update when the data updates, we need to just focus on the data refresh script. In this case, because the data table that drives the report is the source data itself with no changes, the data table settings just need to include instructions to pull data from the database. The beautiful thing here is that those instructions get pushed to JMP Live automatically from the work we did in JMP. There's no adaptation needed here. We can simply indicate that we want to use the source script that is already included in JMP Live.

In the second example, we will need to prepare the data prior to creating the report. Our workflow in JMP involves pulling the data from the database, preparing it, and then creating the report we want off of the prepared data. In this case, we must modify the source script in JMP Live. The source script must include instructions for both pulling the data and preparing it. Here we are in JMP, and we have used Query Builder to pull data from a database and create the report. I'll go ahead and hit play on this animation. You can see here's the Query Builder file, the data table that was pulled from that Query Builder, and the report. Now we're publishing that report to JMP Live so that we can share it with other collaborators and stakeholders. Again, we want to automate the data refresh. When we publish it to JMP Live, we are going to go to the data table settings directly. Here you can see we're navigating to the data table, going to the settings. Really, here it's as simple as saying we want to leverage the source script that already exists in JMP Live. Once we assign the database credentials, we can test the script by clicking refresh to make sure it works, and then we can set a schedule for the script to run on a recurring basis automatically.

Now, in the second example, our workflow, actually I'll go here. In our second example, our workflow requires data preparation before creating the report. In this case, it involved concatenating two columns and renaming the column to get Drug ID, Description. In JMP desktop, we used Query Builder to pull the data. Then we grabbed the JSL for the data preparation steps from the log and included it in the postquery script. We then publish the report to JMP Live and want to automate the data refresh. Our data refresh, again as a review, will need to include instructions for both pulling the data and preparing it. Here you can see a picture of the Query Builder file that includes the data preparation steps in the postquery script area. Occasionally, users will also include the JSL that creates the report in the postquery script as well. Now, when we publish a report that is a result of this Query Builder workflow in JMP, whether it includes data preparation steps only, or data preparation steps and the report JSL, when it gets published to JMP Live, the source script, or sorry, the source script that's included in the refresh script will include the postquery JSL in the New SQL Query statement.

Here I've got it highlighted here. In JMP, we had the data preparation steps in the postquery script, and when we published the report to JMP Live, the data table source script put that JSL inside of the New SQL Query wrapper. The behavior is not fully predictable when you use the source script that has JSL packaged inside the New SQL Query. If we want the data preparation to occur consistently as part of the data refresh script, we will need to modify the source script. Here we're starting again with that Query Builder file in JMP, and you can see here the postquery JSL we have here at the bottom. To get a refresh script that will successfully include data preparation steps, we will create one in a script window in JMP that will then be copied and pasted into JMP Live, replacing the source script that's there. I'll play the video here, and you'll see the best thing is to remove the postquery JSL, copy it into memory, and then we save the run script for the Query Builder file, which will only include instructions for the database pull. We can then paste in the data preparation steps that were previously copied and then end the whole script with a Data Table call, which is necessary for a JMP Live script.

We'll copy it, and then we're going to JMP Live to replace the source script that was there. Again, we can click Refresh to make sure the script works before we set up that schedule for the script to run automatically on a schedule. A quick review. Today, we walked through two examples of adapting Query Builder workflows from JMP to JMP Live. In the first example, it was simple because there were no data preparation steps, and we could simply indicate we wanted to leverage the source script in JMP Live. In the second, we had data preparation steps included. We had to modify the source script in JMP Live, essentially removing the postquery JSL in Query Builder and separating it out from the database pull.

That concludes my section, and at this point, I will pass it to Monique to cover the second example.

Yeah, Wendy, thank you. Let me find the screen to share. Okay. In the second example, we will see how to adapt a workflow for process control charts that have changing spec limits. Many of our JMP customers use JMP Live to publish a report on process health. JMP Live is a very good solution for this because it can make this type of data easily accessible to anyone instantly, for example, on a manufacturing workflow.

Now, the challenge is that process limits do change, and they don't change just once in a while. They do change more regularly, meaning that there has to be a change made. Reasons to change process limits are things like product changes, process improvements, changing customer requirements, etc. It happens enough where having to do this manually is probably not something that people prefer. The question is how to update these reports in JMP Live and make that manageable.

Let's take a look at how this workflow happens in JMP desktop. In JMP desktop, limits like spec limits and control limits are embedded in the data table as column properties. We start with a data table, we apply limits as column properties, we create the report, and then we save that report off, or we publish it to JMP Live.

When working in JMP Live, we want to rethink that strategy of how to approach… how to recreate this report so that it becomes easier to maintain. In this example, we will use the strategy of separating the process data from the limits data. We're going to put the limits data information in a separate data table, and we're going to use report logic, to regenerate the reports automatically when there are changes to the limits table.

Two key components for this strategy. The first part is to capture the right JSL, and we can, as we've just seen and as you all are aware of, capture JSL in many places in JMP desktop. We can capture it from the Query Builder, as Wendy showed, we can capture it from the advanced log, or we can capture it using the Workflow Builder. In this example, I will use Workflow Builder. The second key part is that we can use a reference table function in JMP Live to connect two data tables, and that's a new feature.

Here you see a data table number one. That is the data table that has the process measurements data. The second data table is a separate table that houses the spec limits for these processes in table one.

I used the Manage Limits platform to load the spec limits from table one as column properties in data table one. We're taking these limits here and applying them here in table one as column properties, and I captured that step in Workflow Builder. Then I generated a report. You can see number four is the report that has the Process Health Summary Information, CPK, PPK, etc, and it's showing the run charts with the spec limits.

We're going to publish a couple of things. First of all, I highlighted the Manage Limits step in Workflow Builder. That's going to be key because we want to capture that JSL from that step. We're going to publish two parts. We're going to publish number four, that's the report, and we're going to publish separately the limits data table. When we publish the report, the underlying data table is also going to be captured, so we're going to get that table as well.

What lives where? After publishing the report, we have both the report and the process data in JMP Live. The report will have a refresh script, and that is the JSL to regenerate that report from the process data table.

Our process data table does not have a refresh script. In this case, that is because this wasn't published from a Query Builder. With Query Builder, as Wendy mentioned, that source script gets published automatically as a refresh script for the data table. In this case, we didn't go that route. We could, though. Let me go with this example where this is empty. We have a refresh script for the report, we don't have a refresh script for the data table, but we're going to populate that.

First, let me look at this one. This is the third part. We have this limits table in here. This limits table does not come with a refresh script as well. What are we going to do? First of all, we want to tell this data table that it has to update with the limits from the limits table whenever there's an update. We are going to grab that script from the Manage Limits step from Workflow Builder and put that in the Refresh Data Table area. We're telling this table refresh. Second, we need to tell it where to look. We're going to add a reference between process data table and limits table so it knows where to look for those limits.

Here we see the step of copying that JSL and putting it in the refresh section for the process data table. We just copy-paste that in. Are we done yet? No. We have to modify this a little bit. We have to finish with a call for the data table. We can simply copy that first part Data Table(" _Process Measurements ");, we copy that, we add a semicolon here after the Manage Limits closing parenthesis. That's our glue. Then we just simply add that name, or we can do it a little bit more elegantly and give this a handle dt=Data Table, and finish with the data table dt call. Two ways of doing that.

Next, we link that extra data table. We simply scroll down in our Process Measurements data table, go to Add Data Tables, and search for the data table that is uploaded as well. Now we have established that link. This data table knows where to find the limits table.

Here you can see an example of where I'm navigating to the limits table. Now on my desktop version, I'm putting in new values. I used a script to make those spec limits smaller. I saved it. I'm using the Upload Limits Table in JMP Live to upload a new version of this. We see these smaller limits. Now under Dependents, we see that this Process Measurements data table is depending on this limits table. I'm refreshing here. I don't think that's even necessary. It should update automatically. The Process Measurements table had this report as a dependent, and that has updated automatically as well. We can see those blue lines where the spec limits are very narrow now. All these connections are working just fine in JMP Live.

To summarize, we went from embedded limits to centrally managed limits, which would make it easier to keep a single, governed source of limits and avoid multiple versions. It also is less time-consuming because we don't have to regenerate that report every time we have changing limits.

This is one approach. There is another approach, and I want to show that to you as well. That approach is let JMP do it for you. In this case, I'm navigating to Process Screening, and in this setup, I already am calling for that limits table. I'm asking JMP to look at the limits table while I'm generating the report.

In this step, you see that I'm in a report layer, really. This is the JSL for generating the report, but it was calling for the data table. That means that when I publish this to JMP Live, JMP will recognize that there are two tables it needs to upload in the background. It needs to upload both the process measurements and the limits table. I had them in here already, so I published a new one here.

When we check in JMP Live after this is published, we see that under the script in the report layer, the refresh script is now calling for those two data tables, and below, we can see that it added these two data tables as a reference. All of that happened automatically.

In this example, I'm also showing a new feature where I'm going to the limits table and editing that in JMP Live directly. For Process 4, I changed those values. Now, once those are saved in JMP Live, because the report is dependent on that, it regenerates automatically and is showing those smaller limits. This is a very nice example that works very well for process limits like spec limits and control limits.

Why didn't I start with this example, since this was a hands-off approach? The reason why I wanted to show it the long way is because it took us some time to figure out the logic, what needs to be modified when making those connections, and when wanting to set up looking at data from a different data table in JMP Live. We wanted to really make those connections clear, because this is an example of a broader principle, really, of separating data from metadata. It's important to understand how it looks like.

I hope this was a helpful example. This could obviously also be combined with the example Wendy was showing, where we have an automatic data pull using Query Builder and then adapting that with Wendy's strategy and modifying that script with looking at a limits table to automate the whole thing. Now we're going to switch and look at the third example.

All right. I'll be talking about the third example on behalf of Luiza, who will present live in Baltimore. But this particular example is focused on efficient workflows built around subsets of a master table. It'll be easier to understand this title when we get into the setup here.

Let's imagine a scenario where an engineer in JMP is using Query Builder to query a database table, a single table, to look at Product A's process health. This database table contains process health data for all the products. The engineer is applying a filter in Query Builder to subset the data down to just the product of interest. The engineer creates a control chart from the data and publishes the report to JMP Live.

To automate the updating of the report when new data is available, the engineer sets up a refresh script in JMP Live using the source script found in the data table settings. Here is a look at the data refresh settings. The source script here is displayed, and when we look at the source script that's already populated in JMP Live, we can see that the instructions for filtering the process table down just to the product of interest, so not Product A here, but TWC 400 compact is representing Product A because this is how the engineer queried the data in JMP desktop using Query Builder.

Very simple, the source script can be leveraged, and then the engineer can set up a schedule for this query to occur every day of the workweek and feels a tremendous sense of accomplishment.

Now, let's imagine a scenario where many engineers are using Query Builder in JMP to query the database table to look at their specific product's process health. Each engineer is responsible for a different product. When they share these reports to JMP Live and want to automate the report refreshing, this results in multiple refresh scripts that are querying the same table in the database. In addition, because engineers are not always aware of when database tables are updated with new data, many refresh schedules are configured to run more frequently than necessary.

A more efficient workflow for both the database and JMP Live is one where the master table is published to JMP Live with its own refresh schedule, a single refresh schedule that aligns with when the data is updated. Then each report that depends on a subset of the table simply filters a view from that table in the refresh script. Here you can see a refresh script displayed that calls the master process data, Catalyst Converter Production, that's now hosted in JMP Live with its own refresh script.

The refresh script is simply filtering down a data view of just the relevant product for that report. In this scenario, there's no need to set up a refresh schedule because it relies on a master table schedule, and the result is fewer database queries and fewer refresh schedules in JMP Live.

How do we go about accomplishing this? The first step is to move the data from JMP to JMP Live. This task is likely to be taken on by someone who is a JMP Live administrator or someone who simply has broad responsibilities with JMP Live deployment and adoption. Starting in JMP desktop, this person would publish the full database table to JMP Live. Here, all of the products are represented in this table. As we've seen before, we can set up a refresh script and schedule for this full database table very easily because the source script is something we can simply leverage.

Then the third step is really educating the individual engineers that are accessing that Catalyst Converter Production data on how to set up refreshes for reports based off of the data. They should know that this data is in JMP Live on a refresh schedule, and they should be given instructions on how to update the refresh script with the relevant subset of interest.

Again, educating the community of users who are using JMP Live in this particular table that Catalyst Converter Production is in JMP Live on a specific refresh schedule, and then giving users the JSL that they can use in their refresh scripts to populate the data with just their product. Here in this case, each engineer would simply replace TWC 400 compact with the name of their particular product.

Alternatively, the JMP Live admin could set up that data view for the engineers, so data views for each individual product. Then each engineer could simply point to the data table in JMP Live when they publish their report from JMP desktop. Here you can see once the engineer knows that this data view is in JMP Live, when they publish the report, they can simply reference the data table that just has the filtered view that's relevant for their report.

Today, you saw three examples of workflows we have seen customers automate in JMP and extend to JMP Live. These examples are documented in the JMP Community along with additional examples that represent common workflows and common challenges. Head to the community to learn more, contribute to the resource, and engage in conversations with your experiences related to the topic.

Thanks.