# Editor Workflow Level: Intermediate ## Goal Use a repeatable visual authoring loop: bind the scene object, build the graph, resolve data through Debug Context, then verify the result in Play Mode. ## When To Use This Use this workflow when you are turning an idea into a Flow Graph that should survive iteration, handoff, and reuse across more than one scene object. It is especially useful after the Hello World tutorial, when graphs begin to read Blackboard values, call gameplay instructions, use Guards, or return results into Flow, BT, FSM, or Stack modules. ## Prerequisites * A Flow Graph asset exists. * A scene GameObject has a `FlowCoreProcess`. * Required `Blackboard`, `SceneBlackboard`, or `GlobalBlackboard` data is available. * You can open the Flow Graph editor. ## Where To Find It Most authoring starts from three places: * The scene GameObject Inspector, where `FlowCoreProcess` and Local Blackboard references are bound. * The Flow Graph asset, where nodes, ports, comments, and serialized graph data live. * The Flow Graph editor, where Debug Context, node editing, summaries, and visual debugging are used. ## Workflow 1. Bind the runtime owner. Select the GameObject that should run the behavior. Add or confirm `FlowCoreProcess`, then assign the Flow Graph asset. Treat this GameObject as the runtime owner for debugging, Local Blackboard scope, lifecycle Triggers, and Play Mode verification. 2. Bind data by scope. Add Local Blackboards to the process `Local Blackboards` list in the order your graph expects. Use Local data for per-object state, Scene data for scene-shared state, and Global data for cross-scene state. Start with Local when learning or debugging because it is easiest to inspect. 3. Open the graph. Open the Flow Graph editor from the menu or by selecting the graph asset. Confirm you are editing the same asset assigned to the runtime owner. If the asset is shared by multiple objects, remember that the graph structure is shared while Local runtime data is per process. 4. Set Debug Context. Set **Debug Context** to the GameObject with the `FlowCoreProcess`. This lets summaries and value previews resolve against the selected process. Debug Context does not change the graph asset, does not add Blackboard keys, and does not execute behavior. 5. Create a clear start point. Add a `Trigger` for event-driven behavior or an `Enter` node for named external calls. Use names and settings that describe the gameplay event, such as `Start`, `Interact`, `OpenDoor`, or `AttackRequested`. Treat Entry names as a public contract when code or another graph calls them. 6. Build the first chain. Add the smallest connected path that can produce a visible result. Connect nodes left to right, keep the main path readable, and avoid adding optional branches before the first result works. For a data-driven check, wire a Guard or Condition before the side effect rather than hiding the decision in a later node. 7. Configure values. For each instruction, condition, or node field, decide where the value comes from: Literal, Blackboard, payload, TempPayload, or a target resolver. Confirm scope, index, key spelling, type, and list vs single value. Use Summary and Value detail while doing this pass. 8. Add authoring notes. Use comments for design intent, not for restating node names. Good comments explain why a branch exists, what gameplay rule it represents, or what other system depends on an Entry name. Keep comments close to the relevant node group. 9. Verify in edit mode. Before Play Mode, select key nodes and read summaries. Resolve missing keys, wrong types, disconnected ports, and suspicious scopes. If Summary or Value detail is hidden, enable the detail toggles while debugging. 10. Verify in Play Mode. Enter Play Mode and trigger the behavior once. Watch the Console, scene result, Blackboard values, and visual debugging. If the result is wrong, use [Debug a Running Graph](/flow-core-docs/documentation/how-to-guides/debug-a-running-graph.md) before adding more nodes. ## What Changes * Editing nodes, ports, comments, and graph settings changes the Flow Graph asset. * Assigning the graph asset, Local Blackboards, and component references changes the scene object or prefab. * Editing Blackboard keys changes the selected Blackboard component or asset. * Setting Debug Context changes only editor interpretation and preview. * Entering Play Mode creates runtime state; Play Mode changes are runtime-only unless another persistence workflow saves them. ## Verify the Result A graph is ready to hand off when: * The correct `FlowCoreProcess` owns the graph in the scene. * Required Local, Scene, and Global data are bound intentionally. * The graph has a clear Trigger, Entry, or module root. * The first runnable path produces a visible result. * Node summaries resolve without obvious missing data. * Entry names, Blackboard keys, and comments explain the authoring contract. ## Common Mistakes * Editing a graph asset but testing a different asset in the scene. * Forgetting that one graph asset can be shared by many runtime owners. * Reading Local data without adding the Blackboard to `Local Blackboards`. * Adding many branches before one path has a verified result. * Choosing Scene or Global scope only because it is convenient. * Renaming an Entry after code, another graph, or a team member already depends on it. * Treating Debug Context as runtime state instead of editor preview context. ## Related * [First 15 Minutes](/flow-core-docs/documentation/tutorials/first-15-minutes.md) * [Graph Editor](/flow-core-docs/documentation/editor-guide/graph-editor.md) * [Debug Context](/flow-core-docs/documentation/editor-guide/debug-context.md) * [Blackboard UI](/flow-core-docs/documentation/editor-guide/blackboard-ui.md) * [Graph Debugging](/flow-core-docs/documentation/troubleshooting/graph-debugging.md) * [Flow Core Settings](/flow-core-docs/documentation/reference/flow-core-settings.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://flow-core.gitbook.io/flow-core-docs/documentation/editor-guide/editor-workflow.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.