Exactly what Zac says 👆

I use our ticketing system because it works perfectly for this.  But before we had that available, I had a simple form and used it for years.

I also want to make a suggestion from my own experience:

About a year ago, I started a revision history of forms processes within the repository.  I started after burning myself a few too many times.  This has given me a way to revert changes if I have needed to and a central place to see revision history per-process and which tickets were involved, so I can easily ensure I don’t overlap changes without realizing.

I could have also done a database and a form for this, but a folder structure with some simple metadata worked great and was super easy to set-up.

Before I had the revision tracking, I had an incident where some very large changes on a process were stuck waiting for the requestor to approve migration to production for an extended period of time.  They were working on a procedure and other documentation and were stuck themselves waiting on some necessary items from management and the training team.  I accidentally deployed the changes to production accompanying a different ticket for a much smaller change requested by a different member of their team.  I totally forgot the first request was on long-term hold and didn’t see the prior ticket when the new one was opened because they were from different members of that team.  I had no way to revert all those changes once the error was realized.  It was a mess.

With this tracking, when a new request starts, the first thing I do is check my revision history and confirm every prior change on that process is complete.  Then I export a copy from both production and development environments so I have a starting point on both.  As I work on process changes, I’ll periodically save a copy to my revision history.  And finally when migration happens to production I save a final copy from both environments.  So I have multiple points I can revert to if I need to.

Hope this helps!