cancel
Showing results for 
Search instead for 
Did you mean: 

Best practice for documenting changes?

PvD_SE
Level 12
When we make changes to a process or an object, we require the reference-id of the change and a short description to be written in the Page Information stage on the page where the change was made, as well as on the Main Page (for an process). Upon saving the changes the reference and short description, completed with developer name (initials) should be provided in the Save dialog window.

The above gives us at least rudimentary traceability as the reference points back to an errand system where the changes and subsequent testing are documented on a more detailed level including screen-shots.

In order to fill out the reference and text in the Page Information stage, you double-click it, then click in the Description field and start pecking away. Unfortunately, this Description field does not allow for resizing and tends to be too small to get an overview of what has been written there before - something I will propose BP to implement in an upcoming version.

Now for my question:
How do you folks document whatever changes you make in BP processes and objects?

------------------------------
Happy coding!
Paul
Sweden
------------------------------
Happy coding!
Paul, Sweden
(By all means, do not mark this as the best answer!)
1 REPLY 1

EmersonF
MVP
Hi Paul, fine?
I recently used an unorthodox method for this, as the automation code I saved externally via git, today for each code update I generate a release note, a type of readme with a timeline of changes and we record this in a microsft channel teams the push/merge id with the release note update

------------------------------
Emerson Ferreira
Sr Business Analyst
Avanade Brasil
Recife
+5581988869544
If my answer helped you? Mark as useful!
------------------------------
Sr Cons at Avanade Brazil