When you deploy your implementation to GTM, a relationship is formed between Apollo, your GTM container, and all of its components. As a result, any manual changes you make in GTM could effect Apollo or your GTM container and may have unintended consequences.

Adding Additional Components

Any GTM components you create outside of Apollo-managed components will not be overwritten by subsequent deployments. These include:

  • Tags you manually create

  • Triggers you manually create

  • Variables you manually create

  • Templates you manually add

  • New Workspaces you manually add, as long as they are not named "Apollo Workspace" or you have not met the 3 workspace limit

Apollo was intentionally designed this way to enable you to add non-analytics tagging and configuration to your GTM Container.

Apollo Managed Components

Apollo will overwrite any changes made to the components it manages during subsequent deployments. During a deployment, Apollo creates a new workspace, "Apollo Workspace", where all of its components are created. Once complete, a version is created from this workspace and set to latest. Then, the Default Workspace is synced with the latest version. In essence, Apollo recreates all components it manages during a deployment. These include:

  • Tags

  • Triggers

  • Variables

  • Templates

It is always advised that you do not make any changes to Apollo managed components to prevent misalignment between your Apollo implementation and GTM container. Since Apollo syncs the Default Workspace with the latest version at the end of every deployment, if you change a component in the Default Workspace, you will have a conflict after a build has completed.

In the picture below, you will see the name of an Apollo managed tag has been edited. After a deploying from Apollo, the resulting in a conflict is seen in GTM.

If you modify any Apollo managed components and create a new version from these changes, when you deploy Apollo will overwrite them without issue as it creates a new version and sets it to latest.

While most changes will simply be overwritten, others can cause future Apollo deployments to fail with errors. If you have mapped an existing implementation, do not delete any components you have mapped. If you would like to remove a component from your implementation, do so in Apollo to prevent any errors. Additionally, do not alter the name of any Apollo managed variables. Doing so will break the link between your Apollo property and GTM variable, ultimately causing errors with your future deployments.

Additional Notes

If you are having trouble identifying which components Apollo does and does not manage, we recommend implementing the Organization Marker feature. When you enable this feature, Apollo managed component names will be appended with a common suffix/prefix in GTM.

Did this answer your question?