There are two ways to fix regression:

Corrective Update Set (Roll Forward)

While not technically rolling back, this is often a safer play in ServiceNow due to the differential-incremental nature of update sets... if your regression was caused by an early update set, it may be impractical to roll back all the updates subsequent to the one that caused the regression.

If you can develop a fix which will effectively correct the regressed feature, you create an update set in development and advance it through to prd per ordinary procedures (with allowances for appropriate alacrity in emergencies/release band-aiding--providing you document what you do).

Back Out (Roll Back)

You can also perform a true roll back. The latest update set will have a "Back Out" UI action. This action will back the update set out and reverse any changes it effected. This is only available on the most recently applied update set, which forces you to peel them back in order. So you back out in reverse order until you reach the update set that caused the regression.

This is only practical when the regression is caused by a relatively recent update set, and even then, our experience is that back out doesn't always completely reverse changes, especially at the schema level. But we have done it on occasion. See the wiki section on Backing Out for more info.

Rollbacks should be documented in at least two ways:

• In the change request (as an annotation or encoded in the status, i.e. "not implemented" or "partially implemented", provided something like those options still exist.
• In the release document (created at the start of the development cycle. Just make it clear what happened, i.e. which/all features removed).