Hi @MitchellTe1
There is no detailed “order of operations” or official "sequence" doc like in Tealium.
However, in practice, Tags follows this typical flow:
- The library loads and initializes extensions first. Depending on your tag, you may have some global configurations that should be run asap.
- You can use Library Loaded rules to enrich the functionality of your library for instance, define global helper functionalities in a custom code block that can be used later (up to you whether you define a window scope or attach the functions to the _satellite object). See "trigger()" section below
- Rules are processed in priority order whenever their triggering events fire (e.g., page load, click, custom event).
- The out of the box rules Launch comes with fire in the order
- Library Loaded - Launch script has loaded
- DOM Ready - standard browser event
- Window Loaded - standard browser event
- There are other ootb rules like "Direct Call", "Custom Event" or "Click" which can fire at any time
- Important is, that when multiple rules fire for the same event, their order is set by rule priority, but within a rule, actions run top-to-bottom. This order can be set on every event in your rule and defaults to "50"
- Custom code can be used is executed within the context of actions and conditions in rules, or within extension modules.
trigger()
- In most cases, you may already find the out of the box events sufficient to trigger your rule, but sometimes you may have custom requirements that cannot be baked into an ootb event (or you prefer coding a couple of lines yourself.
- The trigger function can only be used within a custom code Event and lets you control when a rule should trigger
- In other words, you can delay the execution to whenever you need it. In that case, you are responsible to keep triggering your own checks e.g., through an interval, and only trigger() as soon as the conditions apply
In my case mentioned in the beginning, where I add functionalities to the _satellite library or a window scoped library object (you must always make sure that you do not overwrite Launch functionalities!), you can bake this into a single custom code rule


Example:
When using Web SDK and sending in Adobe Analytics data to your datastream, you may miss some of the AppMeasurement plugins like "apl" (append to list).
Since I am lazy, I like to enrich my _satellite object with the publically available plugin code to make use of it, just not within the classic "s" Adobe Analytics object, but as part of my _satellite Launch library instance.
Now, you have two options, which none of is any better than the other.
- create a Custom Code rule and throw the code in there -> use trigger(); as last line in your code to execute the rest of the rule to execute actions in the same rule
- create a Library Loaded rule and throw it into a Custom Code block in there
It really does not matter, there is no right or wrong from what I can tell, it just gives you more flexibility to keep your setup simple.
The Custom Code event's code block would then look somewhat like this:

Cheers from Switzerland!