Hello,
I’m working on a customization that extends a standard Acumatica screen. I’ve added several new fields, and this customization is part of our module. When we deploy the module, we also want to deploy the related help content.
I created a new Wiki and successfully added help articles for our custom screens. My question is: How can we deploy an updated help article for a standard Acumatica screen as part of our module?
Any guidance or best practices would be appreciated.
Best answer by Steve Milner
@HristinaP77 A standard help article can't go into your package the way your own articles do. A customization project only carries wikis saved in your tenant, and all of the standard help lives in wikis owned by the hidden System tenant.
The obvious workaround is an article with the same ID in your wiki. In 2026 R1, Open Help finds its article by an ID built from the screen ID and searches every wiki: SO_30_10_00 for the Sales Orders form reference, SO_30_10_00_NAV for the menu the button opens. Your wiki can hold those IDs, since the editor only checks for duplicates inside one wiki. With two matches, which one Help shows comes down to internals like revision numbers and GUIDs. That isn't documented, so I wouldn't ship a module on it.
One more thing for new fields: the description in a field's infotip (the ? next to its label) isn't pulled from any wiki article. It lives in a separate table keyed by screen, view, field and language.
I'd leave the standard articles alone and document your new fields in your own wiki, one article per extended screen, with IDs that don't match the standard ones. After each change, click Reload from Database on the project's Wikis page so the package picks them up.
+4@HristinaP77 A standard help article can't go into your package the way your own articles do. A customization project only carries wikis saved in your tenant, and all of the standard help lives in wikis owned by the hidden System tenant.
The obvious workaround is an article with the same ID in your wiki. In 2026 R1, Open Help finds its article by an ID built from the screen ID and searches every wiki: SO_30_10_00 for the Sales Orders form reference, SO_30_10_00_NAV for the menu the button opens. Your wiki can hold those IDs, since the editor only checks for duplicates inside one wiki. With two matches, which one Help shows comes down to internals like revision numbers and GUIDs. That isn't documented, so I wouldn't ship a module on it.
One more thing for new fields: the description in a field's infotip (the ? next to its label) isn't pulled from any wiki article. It lives in a separate table keyed by screen, view, field and language.
I'd leave the standard articles alone and document your new fields in your own wiki, one article per extended screen, with IDs that don't match the standard ones. After each change, click Reload from Database on the project's Wikis page so the package picks them up.
Thank you so much for your suggestions! We decided to move forward by adding a separate article only for the new fields in the standard screens.
Thanks!
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
