# Groups
If an app has over 10 modules, the modules should be put into groups. These groups should be named after the entity with which the modules work or the type of job the modules are executing.
Consider the following when you decide the order of groups and modules in your app:
* Triggers
* All instant triggers
* All polling triggers
* Generic modules
* Sorted in groups, if possible
* Example of a group: RECORDS
* Typical modules divided by business logic
* Sorted in groups (examples: TASKS, DEALS, CONTACTS)
* Sorted from the most important to the least important
* Ordered by RCUD logic (read, create, update, delete)
* Other
* Examples: Make an API call, Execute a GraphQL query
Example of the order of groups
Example of the order of modules in a group
TRIGGERS
FORMS
TASKS
DEALS
OTHER
FORMS
List forms
Get a form
Create a form
Update a form
Delete a form
When dividing modules into groups by business logic, if every group only has one module, do not apply custom grouping. Instead, use the default groups: ACTIONS and OTHER.
Correct group structure
Incorrect group structure
---
# 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://developers.make.com/custom-apps-documentation/best-practices/naming-conventions/groups.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.