Build Rules are found within a configurator output build. They control two things:
- which output within a build is generated when the build is called. This is a Before Build Rule.
- what information is placed within the output. This is an Output Rule.
For detailed information on controlling what information is placed within a specific output using an Output Rule, read this step-by-step walkthrough for creating an output document.
Creating Build Rules
Within a configurator, in the design tree, open the "Builds" category. If you do not see any builds listed, click the + symbol to create one. In this example our sportscar configurator has two builds for Sales and Engineering.
Open the build to see its outputs. If you do not see any outputs listed under the build, click the + symbol to create one. Here, opening the example "Sales" build shows three outputs listed under the Outputs folder.
- To control which outputs within a build are generated when the build is called, create a Before Build Rule, under the rules for the build itself. By default, builds do not have a Before Build Rule, so all outputs are generated.
- To control what information is placed within the build, then create an Output Rule under that specific build.
Before Build Rule Example
Output rules run only if their output is active. By default, each output is active but this property can be changed. To disable an output, create a "Before Build" rule with Snap logic. Here's an example Before Build Rule for our example sportscar configurator's "Sales" build. We first disable all the builds, then determine which builds will actually run based on the CurrentState field.
Output Rule Example: localizing outputs
You can give your users output documents in their own native language and format by localizing them. To localize an output document, such as a quote or a bill of material (BOM), first ensure you have a working output document in your base language. Then follow these steps:
1. Create an output document for each locale
Duplicate your existing document, and edit it to match the needs of the particular language. You'll replace the text, of course, as well as make any formatting adjustments. Remember to focus on language changes. Don't focus on geographic changes, such as how shipping fees are different when selling to Mexico vs. Ecuador in your "ES" Spanish template.
2. Store the user's locale
Save those documents under your existing build. For example, if your "Sales" build was in English before, it's in 3 languages now:
3. Use that stored locale to activate the correct output document
Create a hidden field in your configurator (here, we call it "theClientLanguage"). Then create a Loaded Rule that fills this hidden field with the user's locale:
Why do we do this?
The get block that offers you the clientLanguage is available only when the configurator is running in your user's browser. When your user leaves the page or closes her browser, the UI no longer exists. Therefore, the clientLanguage of that browser also disappears. If we store it, however, then we can access it in later processes or server-based processes, like sending email messages or generating output documents.
Now that you've stored the user's locale, you can use it in the future after the user has closed the browser window and walked away. For example, you can use that stored locale in an output rule for your German version of the BOM in your "Sales" build:
