Nate Lust added a comment - 18/Dec/18 11:02 AM - edited I really debated, in the task I linked you to, whether or not to couple the setting of the templates to that config variable, or write out the string "deep" again. This primarily arises because of the shard CmdlineTask PipelineTask code base. I am not sure which is the best way to go in that case. Since linking to that I have finished converting the deblending tasks here . The idea going forward is that you could have a few strings that are templated together, and set that default in the config setDefaults. Then in config overrides you could do something like config = DeblendCoaddSourcesSingleConfig() # Set all names to some common sub string for bulk changes, for instance running # Single frame processing normally, and then a second time, but output everything # prepended with fakes config.formatTemplateNames( 'Princeton4Life' ) # override just the output catalog name, because something special is planned config.measureCatalog.name = "UWRulesPrincetonDrools" This is different to the example I gave at the PCW with getOutputDatasetTypes(). The problem with that method is that very often many different methods needed to be overridden in every class just to format these strings. This new way of doing it pushes where you supply the name string into a function call instead of a config parameter, but simplifies writing PipelineTasks. I will note that the nameTemplate does not go away after calling formatTemplateNames, so if there was some other more specialized workflow, it is still possible to implement a getOutputDatasetTypes method that looked at a config parameter to set that string a second time. This just simplifies the need to do it to a bulk number of parameters all with a common string.