Skip to content
Release: Australia · Updated: 2026-03-12 · Official documentation · View source

Clone an instance with a SAML integration

Clone an instance with a SAML integration. Before you clone an instance that uses SAML 2.0, preserve the SAML SSO-related settings on the target instance or you might make the target instance inaccessible.

Before you begin

Role required: sso_config_admin, business_rule_admin, script_include_admin

Procedure

  1. On the source instance, navigate to System Clone > Preserve Data > Core Instance Properties.

  2. Make sure that the following SAML SSO-related properties are preserved using conditions.

    • glide.authenticate
    • glide.security
    • glide.entry
    • glide.script
    • glide.session
    • glide.saml2
    • com.glide.communications
    • com.snc.integration.saml_esig
Image omitted: DataPreserverSAML.png
Data preserver SAML.
**Note:** When you create the clone, include attachments so that certificates carry over to the target instance. Also, make sure the **Theme** check box is cleared so these properties are preserved regardless of whether you preserve the instance theme.
  1. On the source instance, navigate to System Clone > Preserve Data to preserve the SAML certificates on sys_certificate and SAML users on sys_user related to SAML/SSO/Multi SSO.

    If you need them, export them into XML, then manually import them on the target.

    Warning: Do not try to clone the SAML/SSO/Multi SSO setup from one system to another. Most transfers of SAML/SSO or Multi SSO settings do NOT work because they must be configured on the identity provider. If you overwrite a working setup, the target instance will fail to authenticate so your target instance will become inaccessible. Also, do not change the sys_id of your Multi SSO provider record; doing that will force your users to flush their cookies. For more information about cloning precautions, see Checklist before cloning an instance.

  2. Exclude the Multi SSO tables sso_properties, digest_properties and saml2_update1_properties.

  3. Manually create the SAML/SSO/Multi SSO records on each instance independently and set up the records on your identity provider as well.

  4. Make sure that you manually create a LOCAL admin account on sys_user (not in LDAP or SAML) record on the target instance and with a sys_id that does not exist on the source instance.

  5. Click Update.