> ## Documentation Index > Fetch the complete documentation index at: https://docs.go.gbgplc.com/llms.txt > Use this file to discover all available pages before exploring further. # View interaction groups > Learn how to view interaction groups, understand where each data element comes from, and control where the platform collects data in your journey. When you create a journey, the GO platform automatically generates an interaction group based on the domain elements required by the modules in your flow. This applies to both [low-code Hosted journeys](/docs/go-v2/low-code-builder/introduction/hosted-journey) and [API-first integration](/docs/go-v2/developer-integration/overview), including integrations that use the official [SDKs](/docs/go-v2/developer-integration/sdks/overview). The interaction group appears as a node in the Journey builder, positioned before the first processing module. This guide explains how to view an interaction group, understand where each data element comes from, and control where in the flow the platform collects each element. For the concepts behind this guide, including [interaction groups](/docs/go-v2/get-started/key-concepts#interaction-groups), [domain elements](/docs/go-v2/get-started/key-concepts#hosted-journey-concepts), and [pages and cards](/docs/go-v2/get-started/key-concepts#pages-cards-and-screens), see [Key concepts](/docs/go-v2/get-started/key-concepts). ## Before you begin Before you can view an interaction group, ensure you have one or more modules added to your journey and that you have selected **API + hosted (latest)** as the integration method. If your journey uses the API only integration method, then no interaction group is generated and no interaction node appears in the flow. ## How data flows through interaction groups Each module in a journey declares the domain elements it needs as inputs. The platform satisfies each input from one of three sources: * **Collected in this group**: The end user provides the element in the interaction group that sits in front of the module. * **Collected in an earlier group**: The element is collected once, further upstream, then reused. Elements accumulate as the journey progresses, so any element collected earlier is available to every module that follows. The platform never asks for the same element twice. * **Pre-filled at journey start**: The element is removed from every interaction group and supplied through the API in the `context.subject` object when the journey starts. ## View an interaction group 1. Open your journey in the GBG GO Journey builder. If you haven't created a journey, then refer to [Create hosted journeys](/docs/go-v2/low-code-builder/low-code-platform/create-hosted-journeys) to get started. 2. In the journey flow, locate the interaction node. This is the green icon positioned between the **Start of journey** node and the first processing module. Interaction node in journey flow 3. Click the interaction node. The interaction group panel opens on the right side of the builder. The panel is titled with the group number, for example **Interaction group 1**. The panel contains the following sections: * **Add data to this group**: A list you use to add a data element to this group. * **Data elements**: The domain elements collected in this group. Each element appears as a tag with a remove icon. * **Pages**: The screens the platform generates for the elements in this group. ### Data elements The **Data elements** section lists every domain element this group collects from end users, derived automatically from the modules in the journey. Each element appears as a tag with the domain element name and a remove icon. For example, a journey that includes an **Age Verification** module displays data elements such as `FullName`, `DateOfBirth`, `CurrentAddress`, `SSN`, `PreviousAddresses`, `MobilePhone`, and `PersonalEmail`. ### Pages The **Pages** section shows how the data elements are distributed across the [pages and cards](/docs/go-v2/get-started/key-concepts#pages-cards-and-screens) the platform generates. Pages and screens apply to low-code hosted delivery. In API delivery, the platform does not generate hosted screens, so you collect the data elements from your end users yourself. Click the list arrow next to a page name to expand it. When expanded, the page displays the cards it contains. Each card is identified by a card ID that indicates the type of data it collects. For example, expanding the **Personal details** page of the **Age Verification** module shows: * Card ID: NameCard * Card ID: DateOfBirthCard * Card ID: IdentifierCardSSN A journey collecting personal and contact information might organise its cards across four pages: * **Personal details**: contains cards for name, date of birth, and identification number. * **Contact details**: contains cards for phone number and email address. * **Address details**: contains cards for the current address. * **Previous Addresses**: contains cards for previous address history. ## Check where a module gets its data To see where a module collects each input, open the module and view its inputs. 1. In the journey flow, click the module you want to inspect. 2. Select the **Data** tab. The **Inputs** table lists each required input in two columns: * **Name**: The domain element the module needs, for example `FullName`, `DateOfBirth`, or `CurrentAddress`. * **Source**: Where the platform collects that element. The **Source** column tells you where the data comes from, not where it is used. The source is one of the following: * **Pre-filled**: The element is removed from every interaction group and must be supplied through the API when the journey starts. * **Interaction group \[number]**: The source names a specific group, for example **Interaction group 1**. The element is collected in that group. If the group number is lower than the module's own group, then the element is collected upstream and reused. Inputs that the module does not require appear under **Optional inputs**. Click the list arrow to expand this section. A module in a later group can show a source of an earlier group. For example, a module in **Interaction group 4** can show `FullName` with a source of **Interaction group 1**. This is expected. It means `FullName` is collected once, upstream, then reused, so the end user is not asked for it again. ## Control where the platform collects a data element You can move a data element to a different collection point. This lets you decide whether the platform asks the end user for an element and in which group. You can also supply the element through the API instead. ### Move a data element to pre-fill If you already have an element and don't want the end user to enter it, then remove it from the interaction group. The element moves to the **Start of journey** node. It still needs to be supplied, but you now provide it through the API in the `context.subject` object at journey start instead of collecting it from the end user. 1. Click the interaction node to open the group panel. 2. In the **Data elements** section, click the remove icon next to the element you want to pre-fill. 3. To confirm the element moved, click the **Start of journey** node. The removed elements appear here. Any module that still requires the element now shows a source of **Pre-filled** on its **Data** tab. To learn how to supply the data, refer to [Start a journey (partial prefill mode)](/docs/go-v2/developer-integration/execute-customer-journeys/start-a-journey-step#start-a-journey-partial-prefill-mode). ### Move a data element to an earlier group A module in a later group might need an element that isn't yet collected in that group. Instead of collecting it in the later group, you can add it to an earlier group so it is collected sooner and reused. This keeps related data together and reduces the number of screens the end user sees. 1. Click the interaction node for the earlier group, for example **Interaction group 1**. 2. In the **Add data to this group** list, select the element you want to collect here. The element now appears in the **Data elements** section of the earlier group. On the later module's **Data** tab, the input's **Source** updates to point at the earlier group, for example **Interaction group 1**. The element is collected once, in the earlier group, then reused by the later module. Removing a data element that is required by a module in the journey may prevent that module from completing its verification check, unless you supply the element through pre-fill. Review the input requirements for each module before making changes. ## How interaction groups update The interaction group updates automatically when you modify the journey flow: * **Adding a module**: If the new module requires domain elements that are not already collected, then those elements are added to an interaction group and distributed across pages. * **Adding an evaluation node**: Each branch out of an evaluation starts a new interaction group. Modules on that branch collect any new elements they need in the new group, and reuse elements collected upstream. * **Removing a module**: If the removed module was the only one requiring certain domain elements, then those elements are removed from the interaction group. Empty pages are also removed. * **Switching to API only**: If you change the integration method from **Hosted journey** to **API only**, then the interaction groups and all associated elements, pages, and configuration are removed from the flow. All changes to interaction groups are recorded in the audit log. ## Frequently asked questions The domain element moves into pre-fill. Instead of being collected on a hosted screen, it is supplied through the API at journey start. You can't set fields as required or optional individually. In a hosted journey, you can only show or hide domain elements. If you remove a domain element from an interaction group, it moves into pre-fill and is supplied through the API instead. Not directly. To restore a field you removed from an interaction group, delete the interaction group and add it again. The platform recognises the shared field through domain element mapping and collects it only once in the hosted journey. The end user is not asked for the same field twice. ## Next steps Configure evaluation rules to determine the outcome of your journey. Publish your journey to make it available for end users.