Paychex - Tips & Tricks from an Alteryx Ace - Inspire 2017

Not every Alteryx app is created equal, nor is its data. Often, one user wants this set of data while a different user wants that set, even though the underlying app is the same. For example, a model that predicts various client behaviors, including upsell/cross sell propensity and possible churn, might be consumed by several users, each wanting a different data set. And then that data set might change in a month. How can you give your users the flexibility to change the data set quickly and easily in any Alteryx app? In this session, we'll explain how to streamline the process, reduce redundancy, and apply the governance required while creating a self-service app that gives your users ultimate flexibility. We'll also review how to ensure that each user can only view and run the models for which she has explicit permissions.

Video Transcription

Michael Barone:
All right, well thank you for coming, we're going to start. There's a lot to get through. This session is Tips & Tricks from an Alteryx Ace: Deploying Apps and Reporting to the Gallery.

I am going to go over a specific use case for an App that I needed to build and there's a lot to it. I wanted to kind of cover it from start to finish. The objective isn't that when you leave here that you're going to be able to go back to work and do this exact same thing. It's more to give you an idea of the functionality that's three... Or two really useful pieces of functionality that's available in Alteryx.

And you'll have the power point as a reference, the community, as well as the help files and even a sample workflow that's... Already comes with Alteryx for the things that I'm going to show you.

So it's really just to give you an idea of what's there. I will go through... and Alteryx is not going to be completely showing you power points. I'll go right into Alteryx itself and show you what I did.

If you have questions, just jot them down and save them for the end. That way, I can get through everything and then we'll come back to questions, there'll be time at the end.

Okay so, going to give a quick introduction of myself and my company. Go over my Use Case, show you how I set everything up, kind of house-keeping. A lot of people ask, "You have all these files and YXDBs and everything, how do you keep it all straight?" As well as build and deploying the App and then we'll take some questions.

My name is Michael Barone, I work for a company called Paychex, we provide payroll, HR retirement insurance services for businesses across the country, mostly small businesses, 50 or less employees. We do have clients that are larger than that but our bread and butter is the 50 of less.

Been around for a long time, 45 years of about 600,000 clients nationwide. 100 locations across the country, chances are either you or somebody you know receives a paycheck generated by one of our local offices. One out of every 12 private sector employees get a check from us. The department that I am in is the Data Sciences Department and as I'm sure you've heard all week, we take mounds and mounds of data and try to make sense of it all glean useful information that'll benefit the company and our clients.

So major things we do, of course, is ETL, that's getting all the data from all the different sources, blending it all together, mixing it all together as well as then we take that data and we do some predictive analytics on it. So that's where we look at the past and try to predict the future. We'll do descriptive analytics, an example is our small business jobs index. So we will look at and see how employment growth is going in the small business sector across the country. Are small businesses adding jobs or are they remaining stable?

And then we have prescriptive so at the end of a predictive model we'll have a list of clients that we'll give to our end users. And maybe the sales rep wants to focus on what clients are most likely to purchase product X. So if you don't have time to contact everybody, contact these people because they are the most likely.

All right, now Use Case. So once a month, once all our data sources update, we'll go ahead and pull all the data and do that ETL and score all our models. We have several models, about two dozen of them. For this presentation, we're going to focus on a cross-sell for an [inaudible 00:03:27] products and up-sell model, retention model, and price sensitivity. So you can of it at the end of the month, we got all... Our entire client base goes through these algorithms. And it spits out a list at the end saying, "Okay here's your client, here's the model, and here's their score".

Now we score them from A-B-C-D-E-F, so depending on the model, A client is your most likely to exhibit behavior A, sell/buy a product. For like retention model, you might be focusing on your F clients because those are most likely to leave us. So if you want to focus on a retention campaign, you'd go to those clients. Bottom line is you have your client, model, and your score.

The end users that these go out to, marketing, sales, retention teams, and seems like every end user wants a different list so the sales people might say, "Give me this one model and all our A clients". Another organization might say, "Give me all the clients but only if they... regardless of their model score, and maybe they only have 15 employees or less.

So we have lots of lists going to lots of people and every time when a new end user is added or they want something different then actually you have to in and create that output. So I was thinking wouldn't it be nice, if at the end of these processes, we take all the clients, all their scores, stick them here, and then instead of me sending out or writing modules to automatically send out lists to people. How about everybody goes to this one spot, they pick what they want, they could pick their models, their scores, their client attributes, and they get more of a self-service type thing.

Now the requirements is that the data retrieval has to be fast so you can imagine with 600,000 clients, two dozen models, the data set gets both very long and very wide, quickly. So data retrieval could be an issue. Now using the traditional Alteryx tools, the YXDBs, and filtering for what you need. It goes pretty darn fast even with that but I think now it's time to investigate moving over to Calgary. If you notice in your tool palette there's a Calgary palette and what that does instead of outputting data to a YXDB, it'll help put it to a CYXB. And they call it Calgary, I'm assuming, because Calgary is a very large area and we're talking about very large data sets.

And it's a very... You can think of it as a very heavily indexed YXDB so when you are retrieving data from there, using those fields that are indexed, it's exponentially faster than a YXDB. Now they do state that, probably not recommended for under 200 million records only because it's not that much faster and indeed in this App that I am building, the YXDB performs pretty quickly. We're talking a little over a minute which is very good for all those records. But if you're setting a process, setting it and forgetting it. A few seconds here or there doesn't matter. But when you're a user staring at a screen waiting for this data to come back, seconds count.

So I thought I'd try the YXDB and they actually brought it down to 20 seconds depending on what's going on in the server, it could be 10 to 15 seconds. So it's a lot faster.

Now folder and data structure. Again people always ask "How do you keep everything straight?" For this particular application what I did was I started with a high level folder which is what I'll call the App. And then I have three sub-folders, one is the load, that's where we do the ETL, get all the data from all the sources, have it output to the YXDBs or the CYDBs as the case may be. And all the outputs go into the data folder. And then the App is just the App itself so the load is where we get the data, the data is where we put the data, and the App is what draws the data out of the folder.

All right so the first thing I want to talk about is, as I said, not all users have or should have access to all models. So how do I manage that? To start with I have a very simple 3 column spreadsheet and I'll have the user's email address and that's for identification purposes, all the models available to them and then their gallery user ID. When you set up the gallery and a user is added, they get a system generated ID from the gallery that you can see. And that's my ID so if I only have access to everything except retention, the retention model. What I do here is I just leave that blank so if I want to filter for the models I have access to, I just filter for user ID equals me, my ID. Now that's a spreadsheet like I said because it's easy to maintain but when you're talking about building Apps and going up to the gallery you want every input if at all possible to be in an Alteryx format, so YXDB or CYDB.

So I have a quick little App, it's the bottom one there the YXWZ. All it does for all intents and purposes, is takes the spreadsheet and quickly transforms it into the YXDB. And the YXDB is what goes up to the gallery for the App to run.

So, let's talk about the data itself. So, we have one completely separate process that would be a whole other hour to go over. How we get all our client data consolidated. So you can see, typical data set. You have your ID, your unique identifier, the client's name, their address, maybe their phone number, email and number of employees.

So, that's the client piece. You can see that's more suitable for reporting, because we have one record per client, so it's kind of stretched out. Whereas our model data, it comes out in a more normalized formula. So it's unique by the client and the model. So each client may have multiple records.

So, here you can see the first guy there, there's his models, his scores, again, we score from A to F, A-B-C-D-F. The value, not applicable here. Just interested in those first three columns. So, you could think, proceed to the end, what we want to do is hook these two things up eventually. First we want to provide the user a pick-list to pick which models and scores they want.

And then once we do that, we kind of want to filter that bottom table down for just those. But then we want to kind of flip it or pivot it, or cross-tab it, so that we got that as one record per client and then join it to that table there.

So now we have our client data along with our model data side-by-side. And that's the final presentation that we'll give the user.

All right, building and deploying. I'm going to switch over to going into Alteryx, just because power-points are boring, you'll probably get more out of seeing this...

All right. So the first thing we want to do is get into that Calgary format, formatted database, again for quick retrieval. And the client data's very easy. Here's a client table, that's what I just showed you a second ago.

Over here you'll see... This is where the Calgary tools are. I'll just get the Calgary loader, it's just a Calgary output. Now, when you format it, let's let Alteryx do its thing, leave the defaults. All you really have to tell it is where to put it, so I'm putting it here, and again, I let Alteryx select these, just... It's all automatically done.

Now, what happens is, over here in the data folder is, you'll see the CYDB that I just created, and here's all those indexes I was talking about. This is what makes the data retrieval quick. So that's the first piece. That will be used in our App and sent up to the gallery.

Now, the second piece is to get those model scores... Again, this is what I just showed you. Get those into a Calgary format, but I am going to show you what my vision is to have a final product that looks like this.

So, a user logs into the gallery and they see this little pop-up here. Can everybody see that okay? And what they can do... You can see they have all their models and scores. They could either pick all models/all scores, individual model/all scores, or individual scores.

So, anything they want, they could do that. So that's my end goal. So, let's go back to the data. So, here's where we start. How do we get it so that they could use that pick-list? That, if you look on the help files, the community... If you want to write this down, you want to look for key values. Nested key values and trees.

So, this that I just showed you, this is called a tree, and the way you get it to display like that is using key values. So what we want to do is take this data here and just tagging it with model info. So, here's what it looks like coming in. Here's what it looks like coming out.

Just so, if the user has questions and I have to research things, I know what data came from what parts through the model of the client data. So, what we want to do with those keys, is the final output that we want to see that we're going to store in the Calgary format for the models, is just the client, the model, the scores and that tree key.

Now, creating this tree key, again, that's probably a 45 minute session in and of itself. So, I will breeze through it quickly, but again, community help files and also, if you go to help, sample, analytic Apps, tree custom file database, that will walk you through it a little bit as well.

But, so how do we get those keys in there and why do they look funny like that with all those zeros in between? That all has to do with structuring the pick-list correctly. It's really not that complicated to do. It's complicated to understand sometimes. But first you want to start with just grouping everything. So here's all models/all scores configuration. Simply just group by the key in the score.

So, here's all our possible combinations, and then really, if... Always just keep this in your mind as you're building things, I have three levels. I have everything, which is level one. I have models, which is level two. I have scores, which is level three. Each of those have to get a key and they have to be nested, which means they have to roll up to each other. So, you can see, well, I have level two here. I have level three here. I don't have a level one for everything, so let's make one, call it model.

So, the user will see model for level one, they'll see this for level two, this for level three. And okay, so now I got to start my keys. So model, I'll just call it 01. Now, how do I take it and have Alteryx automatically say, "Okay, I see there are four groups here and five instances of each groups. How do I get this Alteryx to name this one, two, three, four and then one one, one two, one three, one four, one five, two one, two two." Lots of ways you could do that, multi row tools. The tile tool is excellent for this.

Very simply you just pick the unique value function and what you want it to nest, and it will pop out, just like I said, one one, one two, one three... And then it's just putting the zeros in. Again, this all has to do with nesting. So it rolls up that pick-list, the keys, if you want to see them.

So the first key I did up here and that was just an 01 and I called it model. The second key is just taking that key and then throwing some extra zeros for the next level. Then again taking that one and throwing some extra zeros so that they all kind of roll up to each other. So, the final product for this press is for they key, this right here is your pick-list, this is what we're going to show the user.

Okay, so what you're looking at here, is just the user interface picture of this table. But now, remember, I said we're going to have to filter this for just the models there they have access to. I'm going to do that in a second. But anyway, this is your pick-list right here and data format as apposed to that pick-list [inaudible 00:15:35] that you saw. So that's fairly small, I'm just going to stick that as a YXDB in my data and I call it tree link to data records.

And what I need to do. Remember, the goal is to be able to filter this client data set. So, here's the client, the models and the scores. If a user picks, "I want all clients with cross-cell value of D, I need a key attached to that. Because when they use the pick-list, remember, this is what they're picking. They're going to say I want cross-cell D. What Alteryx is really going to feed, is this key right here.

So, I need to attach this key to all the cross-cell Ds. So that's what we're doing here. Simple join, linking it on the key and the score, and bringing in the left, everything from the left. So all the model stuff and then just that very last key, that longest key there. I just renamed it tree key, so it looks like this.

So now, if somebody picks all clients with cross-cell A, they're going to pick all clients with that key and they'll come out of this data set. And again, because it's Calgary, and we're looking for one indexed field, it's going to be super, super quick.

So, that is our data load. So, now we have all the pieces. We have our model access, that's again, who has access to what models, we have our client data and our model scores and then we can go ahead and start building our App. Now, the App, this is... Or it's called a chained App. Because remember, we have to get that super pick-list... Right there, this is a super pick-list that the user is going to see. We need to be able, before we display the pick-list to them, Alteryx has to create their own special pick-list for just what they have access to. So how do we do that?

Okay, well, here's the list. Again, I'm the only example. So, I simply filter, like I said, where the user ID equals me. Again, picture this as a hundred people and a hundred user IDs. So, if I'm logging in while I'm building this, I'm going to say filter for where the user ID is me, see that's all I'm doing there. So, I get out of there, everything but the retention model. Okay, so how the heck is the... A user logs into the gallery, how the heck is it going to know who's logging in and how to do it?

Well, if it did know, there'd be a simple action tool, which is up here under your user interface, gallery interface tools. Pick your action tool. Whatever, however it gets who the user is, all I'm doing is taking my expression here, that's right for my filter tool, and I'm just going to replace this here. So, I'm telling it to replace that with whoever is coming in.

All right, so another question is how does it know who's coming in? Well, the text box tool in the interface is for more than just displaying text to the user. If I pick that... this is kind of going on behind the scenes, the user doesn't need to know. I could type this in and say, "Hey, guess what, I'm capturing your user ID as soon as you log in." But no need for that.

So I just leave it blank and actually, just click on this and they don't even see it. So you notice over here, when I run the App, there's some text in there, I'll show you that later, but you don't see any text box for, "Hey, I'm capturing your user ID." How do you do that? In the annotation. It's __cloud:UserId, so what this does, is every time a specific user logs in, it grabs their user ID, and again what they do with it, they throw it in this filter tool.

So, now I only have models that the user has access to. All right, so why did I just do that? Oh yes, that's right, here's my super pick-list, if you want to call it that. And I need to filter it for just those that I have access to. How do I do that? With a join.

So, we're going to join a model key, I don't really care about all this stuff. I just want the information out of here. So, I deselect all the right stuff. So, you can see, now my pick-list is just going to show me the three models I have access to, cross-cell, price sensitivity and upsells.

Now, again, how do we do that to get it into the user interface like that? Yes, I'll breeze through that. Eventually you have to group everything by the keys. So, if you think of the three different levels. Level one is the model, so you group it up model, one description one key. Next one we got the actual level two, so all the models and its keys, then we have all the scores and their keys.

Now, you notice how I renamed everything to key. So that was actually the first key, second key, third key. I renamed them all key, so we have a key description, stack them on top of each other, so that's what it looks like.

Now, to have it look like that... And look how it's going to look on the user interface, I like to sort it on the keys, not necessary but just for visual purposes. So, this is the pick-list that I'm going to see... Excuse me.

So, when I log into the App, this is my pick-list that I'll see. So that's step one. We haven't gotten into the client and the model data yet. So, what I want to do now, is create just a simple YXDB out of that. I'll call it User tree key file. So, this is the special tree that the user sees, specific to the user, that's created as soon as they click the button to run the App in the gallery.

Now, what I want to do, is immediately jump into this next App with... you know, seamlessly. So again, it's called chained App, and the way you do that, if you go into the designer interface and the properties... See this option right here? On success, run another App, and just point it to the App that you want it to run.

All right, so that will seamlessly, with the user not even knowing that... They clicked the button, creates their special, own little user pick-list, and immediately jumps into this App. Now, this is the App that has all the meat to it, again, I'll go over the text box stuff. But just to show you. This is what we want it to look like.

So how do you do that? So what are we starting with here? This is the final step of the last one. This is their own special little list. All right, so here's their own special little list. How do I display it so it looks like a nice pick-list and a user interface that can do that? Well, there's a tool for that, called the tree tool.

And the tree tool, how do I get the tree tool? I want this to display what's in here. Well, you just point it to it. So you see, this is the exact same thing as this. So, you can think of it as, "Okay, here's my own special tree. Here's where I display it as a pick-list. What do I do after I go ahead and actually pick the choices?

Again, I'll kind of go through this quickly. This particular step right here, is where you'll get a lot of value out of the sample workflows, analytic Apps, tree custom file data base. That will walk you through what's going to go on next in this action tool. All you need to do, we need to filter this for what? We need to filter it for what they pick. How do we know what they pick?

Over here, when they're actually picking things, what they're seeing... So if I do this, I'm seeing that I'm picking cross-cell B clients. What I'm actually doing is picking the B key. Remember those long keys? That's what I'm picking. So, what comes out of this tool, is a stack list of the keys.

So 01, 00001, 02, 002, we need to format that into a filter, saying okay, if the user picks this list, then display this one to him. It's a filter tool, and this this is just a place holder, got to put something in there, one equals one, what's going to go in there...

So, here's the one equal one, we're going to replace that with this moderately complex regular expression. Again, this is in the sample workflow, should walk you through it. Anyway, this will get it to look like this. If you're building Apps, if you're not familiar, if you go back to the designer interface and go to the little one where you can test it, this is where you can pick things and go ahead and play with it.

And click open debug, it's not going to run it. What it's going to do, it's going to open a module with all the tools missing and just everything filled in that you picked. So you can see that action tool over here, is building this expression to put in there. And this is basically telling it, whatever I pick here, display them.

So, this can be confusing, because these are all refrained to the same data base. So, here's my own special list, here's my own special list in a nice presentable pick-list. And filter my own special list for what I just picked in my own special list, and there's my results, and this particular thing I picked everything I had access to. So here's everything.

All right, so now we have my own special list, and what I picked for. Now, what am I going to do with it? Remember, back there... Remember the data, the model data. So, now I have exactly what I picked. All we're going to do, is filter this for that. And how do you do that with Calgary?

It's called a Calgary join. So, that's what this tool is. Up here... Calgary join is right there. And this, what you're doing here, this is... you're going to point it to the Calgary data base, so this is the model Calgary data base, and you can think of that in a traditional join as maybe your left, and then this data coming into it as your right. So, normally we join them together left and right and link the keys.

Kind of the same idea, here's your right data, notice the key file. Here's your left data, notice the key. So if you're going to the configuration of this, again, you point it to the App and you tell it, "Okay, join the key on the left to the key on the right."

Here we don't have to worry about joining in descriptions, just the keys. Again, why am I doing this instead of a traditional join? Because it's about 10 times faster. It's super fast. So, I just did that. So, here is my result that comes out of that join. Now, if you notice, this is just the model data. And a regular join you have your left data and your right data.

You could bring in just the left, just the right, both of them. This one, I wanted just the left. I don't care about attaching this to the data set, all I care about is that. So the way you do that is in this action up here. Different things, this particular one is, get query results that match any input record. That's just going to get you the left, if you will.

So there, now I filtered my models for exactly what want. Now, remember, I have to join it back eventually to the client data, which is in reporting format. So one record per client. I just need to flip this, so that's the same. That's your traditional cross tab tool. One record per client. I want the models going across it and the model scores being displayed.

So, I take that and just flip it to that. So, now I have one record per client, all the models and their scores. Now I could do a nice join back to my client data. Bring all the client data in. And oh yes, just in case I have to do any research, I'm just going to tag these fields with a model score prefix so I know. That is your dynamic rename tool. You pick the choice, add prefix or suffix, pick the field you want and add what you want on there as either a prefix or a suffix.

So, now we have that. Now what we want to do, remember our client data which is over here... So, we have our client data. So, you can see I have my branch client number and all the client stuff. Over here I have my branch client number and all the model stuff. So, let's bring them together. Again, a Calgary join. And pointing it to my client data.

Now here's the difference. In the other one, I didn't care about adding all these fields on. I don't care about that, just give me the model stuff. Here, I do care. Not only do I want all the model stuff, but I want all the client stuff. So, that option is right here. This is called join query results. See, I picked that bottom one. That's going to be your, "Give me everything on the left and everything on the right."

And again, you pick your key, tell it what you want to join it to. Same thing and exact value. The only thing you don't get with the Calgary join that you do get with the traditional, is you don't get to deselect that second key. So, here's branch client number, remember I joined it on here? Normally in a select... In a traditional join tool, I just uncheck that box so it doesn't show up twice. That's all I did here, just make it go away. Just deselected it.

See, now all it's doing is deselecting that ID field. So, we now have out final list that we're going to present to the user, filtered for the models and scores they picked and it's showing all the clients and their demographics. Now, what I want to do, this is going... I'm going to present it to them in a CSV format. CSV, a very very flat, very amendable to where they want to put in a data base, excess, equal, whatever they want to do with it. CSV has a nice easy file for them to use.

But, what I also want to do at the end of all my Apps, is send them an email saying, "Hey, it's done. Go get your stuff." If they want to sit there and wait for it, that's fine. But especially since it's only 20 seconds or less. But if they get called away and an emergency comes up, they walk away, their computer shuts down, they forget about it, just a nice little reminder, "Hey your App's done."

But, what's the important thing? You don't want them to get notified the App's done until it's done. So we use a block until done. In other words, this is maybe going to be my email to them. I don't want that occurring until this is all set and done, and actually there. So, I use my block until done, coming off the third. I could have done this off the second one, but it makes it a little more cluttered. So, the email tool.

A lot of questions on that from people. The important thing to remember about the email tool, is on purpose, it will send one email per record. So, if I have 50 records in here, it's going to send 50 emails. Maybe you want that, because maybe you have a group field that a certain group of users get these records, a certain group of users get these, right? Everybody... Maybe each record goes to a different person. Whatever the case is, it's there.

You're going to get one email for every record. I don't need all that. I don't even care about the data, I just want simple email saying, "Hey, go get your stuff." So, how do we do that. Well, first of all, I got to get rid of all these records. Nice easy low resource way. Just pick off the first one. There, now I got a record. Again, just telling it, "Pick the first one record." And I don't care about this being presented to them in the email. If I did, you could use those fields. But the email tool itself, heres a configuration. I just wanted to go to a static person, whoever the user is.

I just want it come from Alteryx automated email. Tip, don't put spaces in here, or else it may error out. No spaces in the front, and then just, client model App complete, and then saying, "Hey, go to your workflow results and gallery and get your stuff."

If I wanted to display stuff in this, in the email or text in the email based on the data itself, then could configure the email tool do that, using these fields of whatever. But me, I don't like to. So, if you remember... This step here and asking them up here to enter their username for their email.

So, all I want to do is replace me, with whoever the are. So, I'm taking... There's that level of coding on the email tool where I have my name and just replacing me with them. How do I get them? Another text box tool. Accept here, I will display it to them, I won't hide it from them, and I'll have it say, "Enter your email." I give them a default so they can just click on that and type their name in there.

Okay, so now we have the, create the special pick-list just for them, and we have the App that uses it, then goes out and gets the client and model stuff and [inaudible 00:31:58]. Now how do we get all that in the gallery and all of it to work?

Let me switch back to here. I went through this, this will be available. Okay, just let me go up here, did it come up? That did not go to the other one. There we go. Okay. So, when you go to deploy an App to the gallery, you'll go to file, the normal thing, files, save as, and you'll see Alteryx Analytics Gallery. If you're hosting it on your own private server [inaudible 00:32:45] then you'll see your gallery's name there and just pick which ever one you want. And soon as you do that...

Sorry, I can use this pointer thing. Soon as you do that, this dialogue will open up, and up here, see that? You could name it anything you want. It will default to what you name the actual module, but you could overwrite that. And then you want to click this workflow assets. This is the important thing with this sort of App thing that I'm showing you.

This is what will open up. It'll show you all the data assets attached to that module. First thing... Now what happens is, whatever assets you send up to the gallery, as soon as a user logs in, it's going to create their own little temp space and it's going to look to overwrite any asset just in that temp space. Just for that user. So unless you send it up there, it's not going to do that.

So, you definitely want to make sure you send the final output up there, which is that right there. So, the CSV file. That way if 10 people log in, all at the same time, they get 10 CSVs that will get overwritten. One for each person. They won't see 10. They'll only see one CSV, but 10 instances of a CSV, unknown to everybody accept the person running it.

And then, of course, you want to set up the second App, because it's going to... That has to kick off after the first one that creates that special tree file. And here's their special tree file. This is another important piece. You need to send that up there. What's being sent up there is what you just saw with me, building it. So it's filtered for me personally.

But again, as soon as a user logs in, they get their own temp space, all these assets are going to be overwritten for just them. So it's going to overwrite that. Now, this is what it looks like in real life. See these text boxes over here? When you join the user interface... I could jump on my computer, maybe I won't. But these are very easy and the user interface designer you had, you could add things to your interface. If you look at the list, it says add. You got a group box, which is just a big box, a label, which is just text box, free text, and a link. So you could put a link in there if you wanted to.

Again, they log in, obviously I don't call it Inspire Model Scores App1. I just call it Model Scores or whatever. So, they log in... and this is... Remember this part, when they click next, all it's doing is creating their own special tree file. So, there's really nothing to show them. But why not explain the App right there and have them click the next one? As soon as they click next, then it opens up to the second App, which they don't even know at all exists, it's the same to them, and there you go.

They have their special little tree file there for their access and their name. And that is it. Now, if you remember way back in the beginning, I said user, not only do they want to pick their own model stuff, but they also want to pick client attributes. So, I only want clients with 10 to 20 employees. I only want clients that have been with us for a year or more. I did not put that into the whole presentation but if you want to see the actual real App that's been deployed, it looks like this.

So, here's all the model stuff up here. They log in, this is exactly what they see. They can pick their model, choices and then down here they could filter down their client list. Maybe by region, maybe by state, number of employees, months of service. The idea is multiple trees.

And again, it's just building that tree file that we had that one YXDB with the model stuff and the keys, we have another one with client and their information. Same methodology, and if you wanted to, something like [inaudible 00:36:20] that has sub-levels, you could even nest your keys so that you have sub-trees.

And that... We have 10 minutes for questions. Yes?

Crowd question:
[inaudible 00:36:38] results instead of like emailing... Instead of emailing the results to the users. I mean, you're sending them an email anyways, just attach the results to it. Is there a reason why you don't do that?

Michael Barone:
They're potentially big. So, instead of sending it out to them, and it might be too big for email even. Because we're talking... You know, if someone wants all clients and all models, 400,000... You know, 4/500,000 records with 24 fields across, potentially. So that way, "Here's the data," you go grab it and then let their computer do the time to download it. Good question.

The question was, why do I have them go get their own CSV, instead of at the very end, whatever list is generated, email it out to them. And the answer is, those are often too big for email.

Other questions? Yes?

Crowd question:
Why do you have them put their email address in, when you can pull it from the user when they log in?

Michael Barone:
You could. Because I didn't think of it. Yes... No, you could. Because it's in that table, right? Remember? It has the... what, the user ID, it also has their email attached. So I definitely could have designed it to do that.

All though, I had one App a while ago, this is why... Because sometimes a boss will have access to it and their subordinate, they might want their subordinate to run it, but send it to them, so they'll put the boss's email in there, so they can go in and get it.

I Think that was a while ago. I think just drew [inaudible 00:38:17] like that because of that reason. But if you wanted to, you definitely could do it your way. Absolutely.

Other questions?

Crowd question:
[inaudible 00:38:26]

Michael Barone:
What's that?

Crowd question:
[inaudible 00:38:32]

Michael Barone:
No, I have not. We been Alteryx users since 2013. From '13 to '14 and a half-ish, we've... It's like you've heard a hundred times this week, we tool all our processes and moved them over to Alteryx. And then, from then on, this is the kind of stuff we've been doing. Then the next step... I actually took the predicted modeling course this week.

We have statisticians that hard coded the models in say, S and R. I use Alteryx to reference their R file, but I want to investigate at least on the possibility using Alteryx to do some of that modeling. So, that's kind of the next step. And then the step after that would potentially be the API.

Crowd question:
How many users do you have and how do you manage the role out, right? How do you drive adoption in your organization?

Michael Barone:
Right now, we're doing it in such a way, because of a small user base. Maybe have two dozen end users there. I mean, the people that have the ability to write Apps and deploy them, there's only eight of us and only one of them does it, me. They don't really get into that too much.

As far as the end users who have access to the gallery, if you take the gallery course... You know, send them out an email, they'll sign up, create their ID, give them their role, then you just go from there.

Crowd question:
But it's only two dozen. So [inaudible 00:39:46]

Michael Barone:
We have about two dozen users of the gallery, yes. Administrator, is just or the gallery. Artisans that publish to the gallery, like I said, there's four of us... There's actually eight, but I'm the only one that does it.

So we don't really use the gallery yet for sharing modules and things like that, only because there's eight of us and we all sit next to each other and we're all on a shared drive. So if we need to share stuff, "Hey, come over here and get that."

If we want to run company-wide and we need to do that, then yes, we'd definitely probably use the gallery for that sort of thing. Right now we're just using it as a way to give end users who don't have Alteryx, a way to stop bugging me every month for this.

Crowd question:
[inaudible 00:40:29]

Michael Barone:
[inaudible 00:40:34] have, and if you ever get up to that many, probably have to come up with a way to make the adding users a little less tedious. Because now, the user will get an email... You tell the gallery to go invite this person, they sign up, then you have to go in and adjust their roles, so that they only have access to do what I... To go get the stuff and not publish or anything.

So there we got into the hundreds, might have to investigate that maybe. Call in to Alteryx to see if there's a way, maybe using APIs or something that we could actually write directly to the [inaudible 00:41:11] databases behind the scenes.


All right, any other questions?

Michael Barone:

All right, thanks again Michael Barone.

Michael Barone:
Thank you.



Pour Démarrer