I suggest you these approaches:

Without Artifactory

In this case, you just need parametrize your current pipeline to receive branch name or tag as parameter.

Workflow could be:

• Before merge your release branch to master , verify existence of tag with previous stable release or create a new one.
• Merge your release (qa, test, or whatever) to master branch
• Execute your current pipeline with master branch.
• If some error is detected, perform a rollback using your SCM ( csv, svn, git, etc). For instance, bitbucket has a revert option in merged pull request section.
• Execute again the same pipeline with master branch as parameter. If rollback was not possible, Execute this pipeline with last stable tag as parameter.

With Artifactory or some Artifact Repository

In this case, you need to adopt a software versioning strategy.Read this sources:

• https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN400
• https://stackoverflow.com/a/46967235/3957754

In the easiest mode, you just need to build an incremental release version of your wars. Spring versions works in a similar way :

https://mvnrepository.com/artifact/org.springframework/spring-core

For instance:

• Today you have a 5.0.0-RELEASE stable version saved in your artifactory and deployed in production environments.
• In the night, execute your pipeline and as final step upload your war api-5.0.0-RELEASE.war to your artifactory.
• One month after, you have a new release version 5.0.1-RELEASE.
• Execute your pipeline and if an error is detected, just download the previous stable version called 5.0.0-RELEASE and deploy it as rollback step.

Other similar techniques

• Create a build of your application using docker and assigning an incremental version.

As a replacement for Artifactory, you can use Github releases or Gitlab packages and follow a scenario such as (assuming a versioning scheme like prod.build_number.short_commit_hash) :

1. Yesterday evening you released version prod.32.ehR456e
2. Today it seems that this version is having issues in prod.
3. Using an automated deployment pipeline, rollback by re-deploying version prod.31.fBr451e stored in github releases or gitlab packages.