> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elementum.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Enable Record Creation through Services

> Enable Services on Apps and Tasks for customer support, help desk, and self-service request portals in Elementum

Services in Elementum add user-facing request intake and self-service to [Apps](/getting-started/build-an-app) and [Tasks](/workflows/tasks). When Services are enabled on an App or Task, external or internal users can submit requests through a portal or form; those submissions create or update records in that App or Task and can drive [automations](/workflows/automation-system) and downstream workflows. Services can only be enabled for Apps and Tasks—they are not a separate object type.

## Services Key Features

Services provide request intake and self-service capabilities with the following features:

* **User-facing portals** — Internal or external users submit requests through a dedicated portal or form, without needing access to the full app where work is tracked.
* **Submission-driven workflows** — Submissions create or update records in the App or Task and can trigger [automations](/workflows/automation-system) that update other records, send notifications, or assign work, so intake and execution stay connected.
* **Standardized intake** — [Layouts](/workflows/layouts) and [Form Builder](/workflows/form-builder) let you control which fields are required and how requests are structured, keeping intake data consistent.
* **Self-service** — Requesters can submit and, when configured, track status without routing every request through a central team.
* **Stages and layouts** — The App or Task keeps its existing [stage and layout](/workflows/layouts) model; you define the path (e.g., Submitted, Under Review, Fulfilled) and which fields appear at each step for both internal users and requesters.
* **Integration with automations and approvals** — Connect Services to [notifications](/administration/notifications), [approval processes](/workflows/approval-processes), and [object data access](/workflows/object-data-access) so submissions flow into your existing workflows and permissions.

<Info>
  Services are a capability on Apps and Tasks. Access to records in the App or Task (including submissions via the Service) is controlled via [object data access](/workflows/object-data-access) and [roles and permissions](/administration/roles-permissions).
</Info>

### Example Use Cases

* IT help desk portal — users submit tickets that become App records for tracking and resolution
* Employee onboarding requests — new hires request equipment or access; submissions create onboarding App records
* Customer support ticket system — customers submit issues that generate cases in an App
* Equipment or resource request portal — requests flow into an App for approval and fulfillment

## Core Concepts

<Accordion title="Stages and Layouts">
  When Services are enabled on an App or Task, it uses the same [stage and layout](/workflows/layouts) model:

  * **Stages** define the path a request follows (e.g., Submitted, Under Review, Fulfilled).
  * **Layouts** define which fields and components appear at each stage.
  * You can show different fields or components per stage so the experience matches where the request is in the process.
</Accordion>

<Accordion title="Submissions and Downstream Work">
  When users submit requests through the Service (on an App or Task), those submissions create or update records in that App or Task:

  * Triggers (e.g., record created or stage changed) can fire [automations](/workflows/automation-system) that send [notifications](/administration/notifications), create or update other records, or assign [tasks](/workflows/tasks).
  * Your team works in the App or Task as usual; the Service provides the requesters’ entry point (portal or form).
</Accordion>

<Accordion title="Forms and Portals">
  Services are often paired with the [Form Builder](/workflows/form-builder) or custom forms so requesters see a guided, standardized form instead of the full record layout. Configure which fields are required and how submissions are validated to keep intake data consistent.
</Accordion>

## Enabling Services on an App or Task

Services can only be enabled for [Apps](/getting-started/build-an-app) and [Tasks](/workflows/tasks). To turn on the Service experience for an existing App or Task:

1. Open the App or Task where you want to enable Services.
2. Click <Icon icon="settings" iconType="lucide" size={16} /> **App Details** or **Task Details**.
3. Click **Set Status Required** over the Services section. This is only required if you have not configured statuses in the [Record Details Layout](/workflows/layouts).
4. Adjust the **Services Settings**:
   * **Show in Services** — Toggle on to allow submissions to be created from the Services feature in Elementum.
   * **Open Status** — Automatic status when the request is submitted.
   * **Closed Status** — Select the status that aligns best with a closed state.

After Services settings are enabled in your App or Task details, records can now be created by customers or your team without access to the app.

## Automations and Services

When Services are enabled on an App or Task, automations run on the same records (submissions create or update records in that App or Task):

* **Create or update records** when a submission is created or the record reaches a stage (e.g., "Submitted").
* **Update records** when approvals complete, when tasks are done, or when data in related records changes.
* **Send notifications** to requesters or internal teams when a request is received or its status changes.
* **Create Tasks** and assign them from submissions so work is tracked in the App or Task.

<Note>
  Service accounts and [agents](/ai-agents/agents-experience) that create or update records in the App or Task need the appropriate [roles and permissions](/administration/roles-permissions). Use [service accounts](/administration/service-accounts) for automated actions and ensure their roles grant access to the App or Task and any related data.
</Note>

## Related Documentation

* [Best Practices](/getting-started/best-practices) – When to use Services vs. Apps vs. Tasks
* [Build an App](/getting-started/build-an-app) – Create Apps and enable Services for request intake
* [Tasks](/workflows/tasks) – Create Tasks and enable Services for request intake
* [Layouts](/workflows/layouts) – Design stages and field layout for the App or Task
* [Form Builder](/workflows/form-builder) – Build forms for request submission
* [Automation System](/workflows/automation-system) – Trigger and actions for submission-driven flows
* [Object Data Access](/workflows/object-data-access) – Control who can see and manage records in the App or Task