# Running Block Lists
## Executing Logic from a Block
To run logic stored inside a list inside a Block, use the appropriate instruction within a **Trigger**, **Condition**, or **Action**:
* Use **Run Instruction Block List** to execute a list of instructions.
* Use **Run Conditions Block List** to evaluate a condition list.
**1. Select the Block**
In the instruction, use the **Block** field to assign the Block asset that contains the list you want to run.\
Once selected, a dropdown will appear showing all available **Instruction** or **Condition** lists in that Block.\
Choose the list you want to execute.
**2. Set the Target (Optional)**
You can specify **who or what** the executed instructions should affect.
* By default, the **Target** is set to `Target`, following standard Game Creator 2 behavior.
* You can override this and choose a specific GameObject, `Self`, or another reference, depending on your needs.
**3. Instancing (Optional but Important)**
> **Note:** In ScriptableObjects, instancing is required and cannot be disabled.
Enable **Instance Block** if the same list will be run simultaneously from multiple sources.
This is important when, for example:
* Multiple **GameObjects** (e.g., rotating gameobjects) use the same logic at the same time.
* Several **enemies** or **triggers** execute the same list inside the Block concurrently.
> **Why it matters:**\
> Without instancing, shared lists may cause interference or unpredictable behavior when triggered in parallel.
***
## Handling Dynamic References
If the selected list contains **References**, each reference will appear as an individual field within the instruction.
* You can assign values to these fields before running the list.
* These values are passed into the Block at runtime, allowing you to customize the behavior dynamically for each call.
**Example:**\
If the list expects a **GameObject** and an **Item**, you’ll see fields for both, letting you specify which objects to use each time the instruction runs.
This enables you to reuse a single logic list throughout your game while tailoring its behavior through references on a per-call basis.
You may also leave reference fields **empty** if your logic doesn’t require them.\
In that case, any instructions depending on unassigned references will respond as designed, such as doing nothing, failing silently, or using default values, depending on their implementation.
