This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Document Constants are effectively global variables for a module. They serve a couple of purposes:
They allow you to change a value in one place and have it propagate to the entire module. An example of this is a SQL Server connection string. When we author modules in house for Alteryx Web sites, we often are pointing to a beta SQL server, but going to production we need to change it to a release SQL Server. It can be a pain to find all the input and output tools, and even with the module dependencies, the intentions are not immediately clear.
The other thing they allow is an easy way to use questions in a wizard or macro without having to set up any actions. This can be handy, especially when you are cutting and pasting tools, you don't have to worry about moving the corresponding action.
As you can see from the screenshot on the left, there are three types of Constants. Engine are purely constants that are set by the engine and available for use in the module. Question constants come from the questions in the wizard or macro. You can't edit the names or add/remove them here, but you can set default values such that your module runs in a test mode the way you need it to. Finally User constants are variables that can be both created and edited in the module settings.
There are 2 ways to use constants. The preferred way is to use them through any Formula, be it a formula tool or a filter or anything else with a formula in it. The Document Constants (all of the types) show up as regular variables that you can use in a formula. The constants can be set as a # or a string in the 4th column of the constants editor. The formula insures that the types are same and that there are no weird string or XML type issues with substituting the text in place.
That is all fine and good, but not everything can be done in a formula. One of the examples above was the connection string to a SQL server. You could convert your module to use dynamic input tools and set the path dynamically, but that is clearly a lot more work to produce.
There is another way of using a document constant. In any configuration of any tool, you can specify a full document constant variable name with % signs around in. If I had made a User constant named ConnectString, I can use in my input tool the string %User.ConnectString% to refer to my variable. To be honest, it is not recommended to use this method for all but the most advanced users. This will be a straight string substitution, with no type safety and syntax checking. It is very powerful, but consider yourselves warned. This substitution only happens at runtime, not configure time. That is why this input tool on the left cannot show a preview. It doesn't know what that connection string means.