Skip to main content
The guide lives with the application source so documentation changes can be reviewed with product changes. Each page is an MDX file and navigation is controlled by docs.json.

When to update documentation

  • A menu, field, status, action, validation, or workflow changes.
  • A role or permission changes what users can see or do.
  • A report or export changes parameters or meaning.
  • A new module, integration, or document type is released.
  • Support identifies a recurring question or error.
  • A screenshot no longer matches the supported version.

Required evidence

Provide at least one of:
  • approved process-owner description;
  • current application screenshot with non-production/sanitized data;
  • test case or acceptance criterion;
  • implemented menu/view/action identifier;
  • release note or issue reference.

Contribution workflow

1

Open a documentation change

Name the affected page, application version, user role, and reason.
2

Update task-first content

Describe what the user is trying to achieve, prerequisites, steps, result, and control checks.
3

Use sanitized evidence

Remove customer, employee, financial, credential, and shipment-sensitive data from screenshots.
4

Validate links and navigation

Confirm every page in docs.json exists and every local link/image resolves.
5

Obtain process-owner review

Operations, Finance, HR, Security, or another accountable owner reviews behavior and terminology.
6

Record the change

Add a short entry to the documentation changelog and update the coverage matrix when evidence status changes.

Writing standard

  • When an English source page changes, update its Bahasa Indonesia (id) and Japanese (ja) counterparts in the same documentation change. If a translation cannot be completed immediately, record it explicitly in the content-status page.
  • Use the exact menu and action label shown in the supported application version.
  • Start steps with an action verb.
  • Separate saving, approval, posting, payment, and closing.
  • State prerequisites and expected result.
  • Add warnings only for meaningful operational, financial, or security risk.
  • Label screenshots with their captured version.
  • Avoid claims about legal compliance, uptime, encryption, or retention unless formally verified.

Definition of done

A page is publishable when its purpose, audience, prerequisites, procedure, expected outcome, error/control notes, links, evidence level, and owner review are complete.
Last modified on August 15, 2026