nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Merging of two workflow

enthusiast

I need to merge two similar but a bit different workflow in such a way the workflow should have the mechanism to recoginize the type of files deployed through that(file/database deployment) and select the approriate task automatically from the begining of the workflow. Is there a way to use conditional statment to select different workflow tasks based on the content-type using it? Basically what I want to do achieve is to develop a mechanism where the common parts of the two workflows stay the same and the rest of the task should be selected based on the Content-type passed to it.

Any help would be appreicated.

Find more posts tagged with

Comments

Migrateduser

If you know the Content Type at the start of the workflow then you can use perl conditional statements to select different paths.

Migrateduser

I've run into a similar situation before. Keep in mind that if you have any user or group tasks that aren't readonly, you run the risk of the user attaching a different content type after you have already selected your path if you build one defined path immediately after instantiation. The solution I came up with was to put an external path right at the end of the set of tasks that were common and have it determine which of two alternate paths to follow based on the metadata of the files attached to the job. It wasn't an ideal solution, but it met the requirement

Adam Stoller

I've run into a similar situation before. Keep in mind that if you have any user or group tasks that aren't readonly, you run the risk of the user attaching a different content type after you have already selected your path if you build one defined path immediately after instantiation. The solution I came up with was to put an external path right at the end of the set of tasks that were common and have it determine which of two alternate paths to follow based on the metadata of the files attached to the job. It wasn't an ideal solution, but it met the requirement

We did something similar - we had externaltasks after any of the (editable) review tasks that, among other things, ensured that all files associated with the task were of the "right type" - and if not - they triggered the error handler with a suitable message indicating the problem.

The point being - it doesn't matter which way you handle it - but if you're going to make it a requirement that files associated with a job are of a certain type (or not of a certain type) - then you need to build into your design (and documentation) a mechanism for handling the eventuality that someone, somewhere, at some time, is going to attach the wrong kind of file to the job.