2020.1

These runtime parameters could be used in a number of ways. Such as in the following
scenarios:
Filtering rules scenarios
A filter condition could be used to compare a date from the record against a date passed in as a
runtime parameter.
For example, a list of document types for a job: the document could have a property with its
document type (e.g., reminder, collection letter, etc.), and the runtime parameter could be a
comma separated list of document types for the job. So a rule would then compare if document
type occurs in the list of document types.
Finishing rules scenarios
Similar to filtering, a finishing condition could use runtime parameters to compare against.
For example, consider if a copy of a print job has to be produced, in which the copies have to
be stapled, while the original print run are without staples. A runtime parameter could be used
during job creation to indicate if the Job Creation is working on the original or the copy.
Without runtime parameters, the same functionality would require two job presets. So this use
case becomes important for relatively complex presets where duplicating the preset creates a
maintenance issue.
External sorting scenarios
External sorting benefits considerably from runtime parameters.
Especially in case of postal sorting, there can be a need for parameters that vary per job, such
as intended delivery date, tracking id, and more.
Metadata properties
The value for a metadata property could be supplied through a runtime parameter. These could
be, for example, the production date, or the name of the current operator.
Page breakdown
Runtime Parameters can be added, edited, removed, duplicated or moved within the Runtime
Parameter table via the buttons to the right of the table.
Page 655