> For the complete documentation index, see [llms.txt](https://docs.ins-pi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ins-pi.com/command/the-portal/data-hub.md). # Data Hub The Data Hub is where records come from. It sits alongside the workbench, lists the tables you are allowed to read, and lets you find records and put them into whatever you are building. Almost every piece of content starts here. You open the Data Hub, find the applications, capabilities, or ideas you care about, and drag them onto a roadmap, a hierarchy map, a TIME analysis, or a table. ## Tables The Data Hub opens on a list of source tables. Each one shows how many records it holds, and the list is searchable, so a large instance stays workable. Which tables appear depends on your roles. The Data Hub reads through the same permissions as everything else, so a table you cannot read is not offered. ## Finding records Select a table and its records are listed. From there you can: * **Search** within the table by name. * **Sort** by most recent, oldest, or alphabetically in either direction. * **Filter** with the condition builder, using the same fields and operators you would use in a ServiceNow list. Records that are already in whatever you are building are marked as added, so you can see at a glance what is in and what is not. ### Class hierarchy Where a table has extensions, the records are grouped by class. Business Application and Technology Service appear as groups under Configuration Item rather than as one flat list. These groups are structure, not records. You cannot drag a class group onto a canvas, but you can add everything in it at once. ### Parent and child Where records form a hierarchy, they are shown as an expandable tree, so a capability and its sub-capabilities stay together rather than being flattened into one list. ## Current and future state Records are listed in two states. **Current state** is what exists in your CMDB now. **Future state** is what is planned but does not exist yet, held in the Future State Repository. A future record can be placed on a roadmap or a hierarchy map next to the real ones, so a target architecture can be modelled without creating configuration items for things that have not been built. A future record that is no longer wanted can be abandoned. Each state can be collapsed independently, and the record counts are shown per state. ## Putting records into content Records are added by dragging them from the Data Hub into the content you are building, or by adding a whole class group at once. What arrives is a pointer to the record, not a copy of it. A record added to a hierarchy map in March shows March's name and today's lifecycle dates. Removing it from the map does not touch the record. The same record can be in as many pieces of content as you like. Nothing about the Data Hub makes a record exclusive to one place. ## Opening a record Records can be opened as a form from the Data Hub, edited, and saved back. Changes are written to the real record and picked up by everything else pointing at it. ## Related * [The Portal](/command/the-portal/portal.md) * [Content Types](/command/the-portal/content-types.md) * [Access Rights](/command/prior-v26.0/configuration/access-rights.md) * [Metamodel](/command/metamodel/metamodel.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.ins-pi.com/command/the-portal/data-hub.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.