Global Customization and OEM

Many "can this be customized?" requests are not blocked by capability. The real problem is choosing the wrong customization mechanism first. This page turns the most repeated support questions into a quick decision guide: should you use Global CSS, Global JS, customI18nPostProcessor(), or createTool()?

If I want to hide buttons, tabs, or cards, what should I use first?

Use Global CSS first.

Those requests only change how the page looks, not what the page does. Common examples:

• hide "Industry Cases" or "Teaching Help" on the home page
• hide "Forgot password" on the login page
• hide "Export" or "Go Edit" in the app marketplace
• hide "User Group" or "Organization" tabs in dialogs
• limit which chart types are visible in chart dialogs

If a stable selector can already target the element, do not start with JS.

If I want to change welcome copy, button copy, or empty-state text, what should I use first?

If you know the i18n key, use window.customI18nPostProcessor() first.

It overrides copy after i18n lookup in a much more stable way than polling the DOM. It is especially good for:

• changing Copilot / Data Agent welcome copy
• changing fixed button labels
• changing empty-state or prompt text
• tenant-level branding copy overrides

Only fall back to Global JS DOM manipulation when the i18n key is unavailable or the copy depends on routing, structure, or render timing.

When is Global JS DOM manipulation actually the right tool?

Use Global JS when the requirement depends on routing, render timing, or runtime state.

Common examples:

• replacing the no-data text after a chart renders
• forcing the browser tab title to remain the company name
• hiding a dropdown option only on a specific page
• redirecting after logout
• blocking /login or injecting third-party statistics scripts

In short: CSS for presentation, i18n hook for fixed copy, JS for runtime-dependent behavior.

If I want the Agent to query internal knowledge or call business APIs, is that also "Global JS customization"?

Yes, but at that point it is no longer page customization. It is Agent capability extension.

That is what window.heisenberg.createTool() is for. Typical cases:

• enterprise FAQ / knowledge base access
• realtime API access for orders, inventory, tickets, approvals
• search, vector retrieval, or third-party SaaS integration
• lightweight actions such as creating a ticket or writing back a remark

If your need is only copy replacement or UI hiding, do not use createTool().

In OEM projects, which layer should handle which kind of requirement?

Use this shortcut:

OEM requirement	Preferred mechanism
Colors, fonts, borders, hiding cards/buttons	Global CSS
Fixed copy, welcome copy, prompts	customI18nPostProcessor()
Runtime-dependent behavior or redirects	Global JS
Enterprise-private Agent capabilities	createTool()

If a requirement mixes presentation and behavior, it is usually a CSS + JS combination rather than one or the other.

What if Global CSS or Global JS breaks the page?

Both have recovery paths.

• CSS recovery: open a URL with no-global-css, for example https://{host}/setting/global-css?no-global-css=true
• JS recovery: open a URL with no-global-js, for example https://{host}/setting/global-js?no-global-js=true

If the page is not easy to access at all, you can also disable the configuration from the backend side first, then return to the UI to repair it.

Why do some "hide this feature" requests use CSS while others use JS?

Because "hide" can actually mean two different problems:

1. the element is already on the page and should simply not be shown → prefer CSS
2. whether it appears depends on route, dialog timing, or runtime state → JS is usually the better fit

For example:

• a fixed "Export" button in the app marketplace → CSS is enough
• a menu item that only appears in a specific route or after a dropdown opens → JS observation is often needed

Further reading:

• Global CSS Settings
• Global JS Settings
• Data Agent Tuning