Guidance

Best Practices

Reusable rules captured during Phase 2 extraction. These are explanatory notes, so they do not use copy buttons.

Redact Before Publishing

Replace customer names, internal URLs, server names, queue names, resource names, credentials, report identifiers, and personal names before adding samples.

Keep Troubleshooting at the Lowest Level

Place a JavaScript troubleshooting note inside JavaScript, an XPath troubleshooting note inside XPath, and a D365 report-ranging note inside the recipe or Transformer topic where it applies.

Use Copy Buttons Only for Code

Only code, XPath, Regex, XSLT, XML, HTML, CSS, or command snippets should have copy controls. Notes, explanations, and checklists should remain normal text.

Prefer Reusable Patterns

Convert implementation-specific work into a generic pattern. If it cannot be generalized safely, leave it out of the Reference Library.

Related Topics

Phase 5 adds related-topic guidance to reduce duplicate entries and make reusable patterns easier to find.

RedactedReviewedCanonical

Knowledge Quality Rules

RuleHow to Apply
Canonical entry firstKeep one main version of a snippet. Put variations underneath the same entry instead of creating duplicates.
Redaction before publishingReplace customer names, project names, URLs, queue names, storage accounts, API keys, environment names, and personal identifiers with placeholders.
Code copy buttons onlyOnly code, XPath, regex, XSLT, XML, HTML, CSS, and command snippets receive copy controls.
Tips stay low-levelTroubleshooting notes and implementation tips stay under the most relevant technical topic, not as new top-level categories.
No personal project contentDo not include personal product planning, sprint notes, business ideas, project source code, or EDST technical content.

Consultant-Friendly Best Practices