2022.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 instance, the record could have a due date, with only documents due in two weeks time to
be selected. Calculating the date "two weeks from today" could be done in Workflow, with this
date then having to be passed as a parameter back to Connect when Job Creation is started.
Another example would be 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.
Paths for storing temporary files can be controlled from Workflow, allowing them to be unique
per Job Creation. This facilitates running multiple instances of the sorting command at the
same time. For instance, Workflow's temporary folder for a process could be supplied.
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.
Page 1233