I very often need my templates and my DM configs to receive information from Workflow. In the past, I passed that information through JobInfos or through Workflow variables that I then had to define in my DM config.
The problem was remembering which DM config/Template needs what information. While desigining my Workflow process, I would often ask myself: “Does my DM config expect that info in JobInfo 7 or 8?”. I would then have to open my config or my template and look it up.
Runtime parameters achieve the exact same thing, except they are explicitly displayed in Workflow, allowing you to set the proper values that the template or the DM Config expects. Let’s say, for instance, Workflow needs to pass the name and path of a dynamic image to the template. Well in that template I create a Runtime Parameter named Dynamic_Image_Path. In my Workflow process, when I select that template for content creation, I immediately see that the Dynamic_Image_Path value is expected and I can set it to whatever value makes sense for the process.
Note that the runtime parameters are specific to each operation: you may pass a set of runtime parameters to your DM Config, and you may pass a completely different set to your template.
Having explicit values like the runtime parameters also makes working in collaboration easier. The person who designs the template can create a set of expected parameters. The person who designs the workflow config will then know what values the template expects (provided the runtime parameters use descriptive names, obviously) instead of having to ask the designer in which JobInfos the values should be stored.
In and of themselves, Runtime Parameters do not introduce new functionality. But they make the passing of information between Workflow and Connect much more explicit and user-friendly.