Choosing and previewing a GOLIVE

On the instance that receives the configuration, open Administration › Instance and operations › GOLIVE. The source must be declared (see "Declaring the source of a GOLIVE").

Choosing

The page lists what the source can provide, module by module: scripts, forms, processes, catalog categories, items and services, ticket settings, configuration settings, email and notification templates, custom translations, languages… To find an item:

• Search (grid toolbar): part of the label, key, module or type, regardless of case and accents;
• the column headers sort and filter (module, type, active, modified on);
• Modified since: only what changed in the source since a date.

Tick the items you want. Dependencies do not need to be ticked: choosing a service brings its category, items, forms, processes and their scripts. An item that cannot be chosen on its own has no checkbox. Ticked items stay ticked from one page or filter to another; Items selected shows how many.

Previewing

Preview the selection reads the package from the source and compares it with this instance, without writing anything here. For each item:

• the planned action: new, modified or identical; for a modified item, the differences show what changes;
• the issues: a warning prevents nothing; a blocking issue will prevent applying. The most common: a group, account, mailbox or machine group not found here (create it, or bind it in "GOLIVE — source"), a module missing or unlicensed here;
• "added as a dependency": the item was not ticked, it is needed by a chosen item.

Some fields may legitimately differ between instances, such as a trigger schedule. The preview shows the source value and the value here; tick Take the source value to replace it, then Save. Without a tick, the value here is kept.

A few rules specific to some items:

• Configuration settings: only those meant to move from one instance to another are offered (passwords, lockout, theme, application name…). Addresses, outgoing mail, connections and secrets stay specific to each instance and never appear;
• Email templates: the sender (address and name) is a choice field, the value here is kept by default;
• Translations: only translations changed in the source appear, with all their languages;
• Languages: activation is copied, either way; the default language is a choice field, and the one here is never deactivated;
• Queries: a query restricted to groups only goes through if all its groups exist here (same code) — otherwise the preview blocks it, so that it is never opened to everyone;
• Menus: entries are replaced by those of the source; an entry whose group is missing here is restricted to administrators. The menu's assignments (who sees it) stay as they are here;
• Dashboards: only dashboards shared with groups are offered; a sharing group added here is kept;
• Redirects and showcase pages: a redirect disabled or a page unpublished here stays so; a deactivation in the source, on the other hand, is copied.
• Scripts: matched by their identifier (the same in every instance), otherwise by their name; a script already here is updated, never created again. Each script goes through the checks of this instance's creation screen (name, timeout of 24 hours at most, 10 retries at most, content of 2 MB at most, parameters) and its name must not already belong to another script here. Otherwise the preview shows "Script skipped" with the reason and the value at fault: that script is not applied, the rest of the GOLIVE is. A process that uses a skipped script is skipped with it ("Skipped along with an element it depends on").
• Scripts of the same GOLIVE: they are also checked against each other, in the order in which they will be applied. Two new scripts with the same name: the first is applied, the second is skipped ("another script already has this name") instead of being merged into the first. A script that takes the name another script of the same GOLIVE gives up, or whose name is taken by a script applied before it, is skipped the same way. The application skips exactly what the preview skipped: promote that script in a later GOLIVE.
• Scheduled jobs: only the triggers of the jobs shipped with the application and the query runs are promoted. The cron of each trigger is a field of your choice: this instance's value is kept unless you tick the source's. A new job or trigger arrives disabled and is listed under "To reactivate"; a job switched off here stays so. A built-in job missing from this instance (module disabled) blocks. URL calls and schedules created by other modules (scripts, connectors, catalog triggers) are not promoted.
• Job blackout windows: copied like the rest; a window switched off here stays so.
• CMDB: object types (fields, translations, group rights) and relation types are promoted; a field or right added here is kept, a right is never removed, and a group missing here blocks. A field with the same name but another data type blocks. Native types (users, groups…) are never promoted. Hand-entered records are selected one by one (those a connector collects stay with each instance): their values complete those here (an empty value in the source erases nothing), relations are added; a referenced record not yet here is left aside and linked by the GOLIVE that brings it. Attachments are not promoted.
• GLPI connector: only the field mappings are promoted, never the connection (address, tokens, agent, schedule). Create and connect the source here first, under the same identifier (slug); a changed mapping requires a full collection.
• Changes: change types (with their approval process) and freeze periods; a freeze scope CI missing here blocks, so that nothing is ever frozen more or less than intended.
• Release: checklist template items and deployment target instances; a notified team missing here leaves the one here.
• Monitoring: alert processing and CI matching rules, upcoming manual maintenance windows. A rule arrives disabled and is listed under "To reactivate"; its event source, specific to each instance, is linked by name. Everything it refers to (source, CI, category, priority, group) must exist here, otherwise it blocks.
• Organizations: relationship types; the one driving ticket visibility is never changed. Rules filling groups from organizations stay with each instance.
• Knowledge base: bases, categories, tags and articles chosen one by one. An article arrives in the source state (published here if it is there), with its languages, tags and attachments, under the same addresses; an article archived here stays so. An edit in progress here is kept but can no longer be published as is: the preview says so, as it does for a base whose access widens. An attachment over 20 MB, or of a type refused here, blocks. The documentation shipped with the application is never promoted: each instance imports it from its version. Rights on bases stay with each instance.
• Directory synchronization and mailbox filters: an AD synchronization rule travels without its connection, which belongs to each instance — created here, it arrives inactive with an empty connection, to complete before activating it; when present, it keeps its own. Its group mappings and the Microsoft 365 ones target the group with the same code; if it is missing here, the item is blocked. New sources and mailbox filters arrive disabled, to reactivate after checking; a filter attaches to the mailbox with the same name, or to the one you bind it to. The log of excluded emails stays with each instance.
• CRM: custom fields, list values, duplicate rules, team roles, lead scoring rules, competitors, pipelines (with their stages), quote approval and order handoff rules, installed base settings, sequences, territories and commission plans. A product, family or CRM role used by a rule must exist here with the same code (catalog and roles are not promoted): otherwise the preview blocks. A pipeline stage added here is kept. Also blocking: a field with the same code but another type, a commission plan already used here whose rules would change, a running sequence whose steps would be removed, a parent territory that would create a loop. Exchange rates, price lists, roles and teams stay specific to each instance.

A frozen preview

The preview keeps the package as it was read, with its fingerprint: applying will cover exactly what is shown, even if the source changes in the meantime. To take a source change or an issue resolved here into account, preview again. Recent previews remain available from the GOLIVE page. To apply it, see "Applying a GOLIVE and viewing the history".