Sometimes, you may want conditional behavior to occur during deployment based upon user input during the “Run Secondary Process” phase. One can define properties inside the workflow which provides handy form elements that can be used for input to make choices for a given deployment.

In this case, we’re going to use a simple checkbox to determine if we want to perform a database update or not with the deployment. Inside the workflow itself, on the properties tab, we’re going to add a checkbox and call it “database.deploy”. If the checkbox is checked its value will be “true” otherwise, it will be “false”. Essentially, we want to run the database deploy step, in our deployment job when the database.deploy property is set to true. By creating properties like this inside the workflow, the end-user will be presented options with these form elements at deploy time.

Note: It is *not* best practice to have different things happen when deploying a build life to the same environment because it can create a situation that can not be rolled back. However, sometimes based on various situations this is unavoidable.

With that, here’s our example:

return Logic.and(
 StepStatus.allPriorIn(new JobStatusEnum[] { JobStatusEnum.SUCCESS,JobStatusEnum.SUCCESS_WARN }),
 Property.is("database.deploy","true")
);

In this example, we’re seeing the “Property.is()” method, obviously if it is set to true, this pre-condition will trigger. However, it is important to note here, that when the checkbox is *not* checked this step will return as “not needed” which is not the same thing as “success”. Meaning, all steps that are executed after this must have the criteria of “Success or Not Needed” if we want them to run, otherwise, all these subsequent steps will also return “not needed” if their pre-condition is simple “previous success”. If that’s too much of a mouthful, then it will be obvious to you why this breaks, once you try it out. Hopefully we’ll save you some frustration here.