> For the complete documentation index, see [llms.txt](https://interfacing.gitbook.io/interfacing-help-files/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://interfacing.gitbook.io/interfacing-help-files/auditors/managing-internal-audits-apps/managing-requirements/import-requirements-from-excel/data-import-guidelines-and-considerations.md).
# Data Import – Guidelines and Considerations
When importing requirements, tests, and/or evidence from Excel, take note of the following guidelines and considerations:
1. **Requirement ID / Test ID / Evidence ID**
To avoid compromising the identification system currently in place, we do not permit users to create their own IDs for requirements, tests, or evidence. Instead, once these items have been imported, they are automatically assigned a unique and incremental ID by the system.
***
2. **Requirement Name / Test Name / Evidence Name**
Users should exercise caution when naming items. To avoid unwanted duplicates, users must ensure that the name of an item is unique to the corresponding application. Likewise, to update these items, users must ensure that any existing names are matched exactly.
As a general note, if an item does not exist under the registered name, it will be created and added to the relevant module.
* For example, if a requirement is imported under a name that does not match any other requirement in the application, it will be considered a new requirement to be added.
If an item does exist under the registered name, its information will be updated accordingly.
* All fields, that is, except for the name field, will be updated for the item, ensuring that the latest data is reflected accurately.
{% hint style="info" %}
If users do not input a name for a requirement or test, the first 50 characters of its description will be taken as the name instead. Likewise, if users do not input a name for an evidence request, the first 50 characters of the evidence procedure will be taken as the name instead. To avoid duplication, users must ensure that these first 50 characters are unique to such items in the system.
{% endhint %}
{% hint style="warning" %}
Please note that if the requirement, test, or evidence was originally created with the first 50 characters of its description or procedure as the name, and users once again upload the same file without providing a new name, it will retain the same 50 characters as the name.
{% endhint %}
***
3. **Frequency & Test Methods**
For both the **Frequency** and **Test Methods** columns, the same naming rules apply.
* If the name for a given frequency does not already exist, it will be created and added to the [**Frequency**](/interfacing-help-files/administration-and-configuration/configuring-application-settings/general-application-settings/frequency.md) form. Similarly, if the name for a given test method does not already exist, it will be created and added to the [**Test Method**](/interfacing-help-files/administration-and-configuration/configuring-application-settings/audit-management-application-settings/test-method.md) form.
{% hint style="info" %}
When updating the test methods for a specific evidence request, it is important to include the previous selections in addition to the new ones. If the Excel file only shows the new selection(s), the existing test methods (if any) will be removed and replaced with only the ones provided in the file. Users must ensure that the updated list includes all the desired test methods for that evidence request.
{% endhint %}
* If the name for either the frequency or test method does exist, however, the existing entry is simply selected for the imported evidence.
{% hint style="info" %}
If users create a new frequency option using this method, they will still need to go to the [**Frequency**](/interfacing-help-files/administration-and-configuration/configuring-application-settings/general-application-settings/frequency.md) form and input the day count for the added entry.
{% endhint %}
***
4. **Requirement Module**
Any new requirements created are listed as QMS-Defined.
IMAGE
***
5. **Requirement Description / Test Description / Evidence Prerequisites & Procedure**
For these columns, text formatting (e.g., typographical emphasis) does not apply. All rows are imported as plain text.
***
6. **Links & Assignments**
To link requirements and tests, users may need to duplicate rows.
* For example, to assign multiple tests to the same requirement, users will need to duplicate the requirement for each test.
* Likewise, to assign multiple requirements to the same test, users will need to duplicate the test for each requirement.
When assigning evidence, however, users do not necessarily need to duplicate all the rows. If an evidence request has been assigned to a test once in the table, it will be registered for all tests of the same name upon import.
***
7. **Multi-Selection**
Multi-selection is only supported for test methods.
***
8. **Blank or Null Fields**
As these templates are merely a guiding tool, the system will disregard any null or blank rows inside them. Users, essentially, will not be blocked from or warned against importing an Excel file with empty fields.
***
---
# 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://interfacing.gitbook.io/interfacing-help-files/auditors/managing-internal-audits-apps/managing-requirements/import-requirements-from-excel/data-import-guidelines-and-considerations.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.
