Writing documentation

[Max Nowak]

Hi,

I'm interested in how all of you document changes in your customer's (or your own, if you're an in-house developer) instances. To me, it's relatively easy to write documentation on a custom application I've built, but I'm not sure what's the best way to document all of those configuration changes on the platform.

For example, for a custom application, I usually deliver a new document that includes everything that's to know about this custom application. For other configuration / customization, though, I usually group specific features into one document, for example, "Inbound Email Documentation", or "Case Management Documentation".

The thing is, I'm a little inconsistent. Sometimes, I cover all changes to a whole process (like CSM), sometimes, I just cover a certain feature (like "Inbound Email" for all processes). Sometimes, it's just one very specific feature that gets its own document, like "Dynamically filtering and auto-populating fields on the Case form".

This leads to me constantly struggling with finding the right "place" for documenting a change. For example, when I'm changing the inbound email action that controls how replies to Universal Requests are handled, do I add this to the existing "Inbound Email Documentation" document? Would it be better to add it to the "Unviersal Request Documentation" document? What if none of those documents exist, do I create a document that covers the whole process, or just this feature?

As I said in the introduction, I'm interested in how all of you handle the "granularity" of the documentation, and what you bundle up together in one document (or chapter, if your documentation is just one huge document).

Thanks for your input,

Max