A workflow is an orchestration of steps which define a build, deployment, test, or utility process. These steps can be a combination of plugin operations or basic workflow operations such as variable assignment, conditionals, or looping constructs. Workflows are configured on each project which allows the project to perform Build and Deploy operations and in the case of Utility projects allows for the execution of desired commands. The Pre-deploy workflow can be used to perform any review for certain deployments like Terraform, Database, etc. prior to running actual Deploy operations to perform validation before deployment.

Workflows are built using Plugin Operations like SOA Build, WebLogic Deploy or Unix Shell as well as other constructs like If, Assign, While etc. Out-of-the-box plugins for specific technologies will be used to complete most of the complicated tasks in workflows, but when necessary, users can use scripting plugins like Shell, Groovy, Ant, Maven etc. to perform custom tasks.

...

Build workflows are used for building a project. This is used to get source files from SCM or other sources and creates Artifacts that are deployed to a target environment. They create a new version of the project which can be made into part of a release each time they are executed.

Pre-Deploy

Pre-deploy workflows are used for performing any activity prior to running the Deploy workflow in a target group. At the end of the workflow, you can use the default output variables FD_REVIEW_REQUIRED and FD_REVIEW_GROUP to create a review task(Human Task) and assign it to one or more groups. Certain plugins have the ability to override the value of FD_REVIEW_REQUIRED automatically when used in a Pre-deploy workflow.

Pre-deploy workflows will execute when a deploy request is submitted if the checkbox to run the pre-deploy is selected. The project should have the Pre-deploy workflow selected in the configuration screen. The workflow inputs for Pre-deploy should be setup to match the corresponding Deploy workflow of the project. The deploy workflow's inputs will be available to the pre-deploy and deploy input and will show on the project deployment and release configuration screen. If they aren't also present in the Pre-deploy workflow, the data will not make it through to the deploy workflow.The Pre- deploy workflow inputs flow into the Deploy workflow inputs. For this to work, workflow developers must use the same name and data type for the Pre-deploy output(with "Return As Output" selected) and Deploy input variables in the respective workflows. To learn more about workflow inputs see Creating a Workflow.

...

Utility workflows are used for executing specific operations on target environment against a specific target group. Utility workflows do not deal with any artifacts or have versions that can be used in a release. Examples for utility workflows include restarting a server, executing scripts, or any job that may need to be run ad hoc. Utility projects will never give a message like the project was already deployed. They are not tied to any project source control settings, and usually they don’t use SCM at all. TipWorkflows are built using Plugin Operations like SOA Build, WebLogic Deploy or Unix Shell as well as other constructs like If, Assign, While etc. In most cases out of box plugins are very useful, but when necessary users can use plugins like Shell, Groovy, Ant, Maven etc. to perform specific tasks.

Excerpt
name Override Project Version
Overriding Project Version If you want to control the project version based on a discovery made during the build workflow execution, then return the FD_BUILD_VERSION output from build workflow. The version can only contain Letters, Numbers, Underscore, Dot and Dash.