> For the complete documentation index, see [llms.txt](https://developers.make.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.make.com/custom-apps-documentation/best-practices/naming-conventions/groups.md). # 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

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 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://developers.make.com/custom-apps-documentation/best-practices/naming-conventions/groups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.