Skip to main content
We’re always trying to improve our platform for our customers. Here, you can get an inside look at what’s currently in beta at Elementum. Remember, this list is provided as a heads-up—not as an invitation to test or a promise of what capabilities may be included. Most customers will not see these features until general availability. For what’s available today, see the most recent release notes.

What to expect

Heads-up, not a commitment. The information below explains how we treat beta features and why delivery and availability can change.
  • Currently being tested. These features are in active development and testing. Behavior and scope may change.
  • No guaranteed delivery date. We do not commit to a specific release date for any feature listed here.
  • No guarantee of delivery. Priorities shift based on resources and customer needs. A feature in beta may be delayed, changed, or not released to General Availability.
  • Limited availability. Some features may be tested by select customers before being released to General Availability. Broader access is not guaranteed until a feature is generally available.
  • Labs badge. Experimental features available in the platform but still being validated are marked with an orange Labs badge in the Elementum UI. Treat these the same way—behavior, scope, and availability may change before General Availability.

Features in beta

This list is updated as new beta features become available to give you an idea of upcoming improvements likely to occur in Elementum. The colored badges indicate the area of Elementum where you will see the update.

Exportable App and Element Activity Log Apps

The configuration history on an App or Element’s Activity Log page can be exported to Excel, with every change recorded as its own row showing what changed, who changed it, when, and the old and new values. Change requests are included with the approval process, approvers, and decisions, and the export runs in the background so it stays in Your Systems Tasks for later download.

SLA Percent of Target Timer Rules Automations

SLA Timer Rules can be configured to run automations at a percentage of the SLA target instead of only at a fixed number of hours before or after the deadline. This adds flexibility when deciding when SLA actions should take place.

Dynamic Approvals: Activity Log Apps

An activity log on Dynamic Approvals records changes to the approval chain configuration, capturing who made each update and what was changed. App Administrators can review this history to audit edits over time and understand how the approval setup evolved.

Attachment Controls for Individual Agents Intelligence

App Admins can enable or disable attachments for each agent independently so users only submit files the agent is ready to process. When attachments are disabled, chat upload controls and automation action attachment options are hidden—including drag-and-drop and paste paths—while text conversations stay available and uploads return when attachments are re-enabled.

Compliance Profiles Org Settings

Org Admins can define Compliance Profiles—named, versioned sets of compliance controls such as GxP—in Settings and reuse them across the platform. Any App, Element, or Task can have one or more profiles applied under Security, with their controls combining so regulated customers can govern just the objects that need it.

Send API Request: Private Key JWT OAuth Automations

The Send API Request action in Automations supports Private Key JWT as an additional OAuth authentication method. Builders can connect to external systems such as Okta that require this client authentication approach.

SLAs: Trigger Automations with Timer Rules Automations

SLA targets can be configured with Timer Rules that use On Demand Triggers to run automations tied to the rule. Each Timer Rule can fire when the SLA is breached or at a set time before or after the SLA deadline.

System-Provided Inputs for Agent Automations Intelligence

Agent builders can choose Agent or System under Provided by for each automation tool input. System values come from the A2A request that starts the turn and pass directly to the automation without entering model context. Missing required values stop the tool unless Agent fallback is configured; missing optional values can be omitted.
Who can configure it: App Administrators with access to configure the agent or Skill and select the target automation.Where to find it: For an agent, open Intelligence → select the agent → Configure → Tools → Run Automation → Input Values. For a Skill automation tool, open Intelligence → Skills → select the Skill → Tools → the tool’s Configuration → Inputs.Prerequisites:
  • This is a beta capability. Confirm with your Elementum representative that your target environment has the system input configuration and runtime support enabled. Skill tools also require custom automation inputs and outputs to be enabled. If Provided by or Inputs is absent, confirm availability before testing.
  • Select an automation with an On-Demand trigger and the input parameters you want to map. The agent must have access to the tool; a Skill must be active and accessible to the calling agent.
  • Configure an authenticated A2A caller that can send the chosen header or metadata. See Connecting via A2A. Use a test environment and synthetic values first. The normal chat preview does not supply an incoming A2A request’s headers or metadata.
Configuration steps:
  1. Open or add a Run Automation tool and select its automation. For a Skill tool, select the App and Automation under Configuration.
  2. Under Input Values, add or edit the automation input. For a Skill tool, expand the input under Inputs. Configure each parameter that needs a system value explicitly.
  3. Set Provided by to System, then select HTTP header, A2A metadata, or A2A message metadata under Input source.
  4. Enter the Header name or JSON Pointer using the mapping table below. Save the source mapping only; do not paste a runtime token into configuration, instructions, names, or descriptions.
  5. Choose Fallback: None keeps the input system-only; Agent allows the agent to supply it only when the source is missing. Agent fallback requires the input’s name and description for the AI. Use None for identity and credential inputs.
  6. Set Required to match the intended behavior. Inputs required by the automation cannot be made optional in the input editor. Save the input and tool, then reopen to confirm the mapping.
Behavior notes:Supported sources and mapping syntaxMetadata uses JSON Pointer, not JSONPath: enter /identity/subject, not $.identity.subject or the full request path. Pointers must start with /; use ~1 for a literal / in a key and ~0 for a literal ~. For example, /identity/a~1b selects the a/b key inside identity.Header names must be valid HTTP field names. Platform headers cannot be mapped: Authorization, Cookie, Set-Cookie, Proxy-Authorization, Proxy-Authenticate, Host, and names beginning with X-Elementum- or X-Forwarded- are reserved, case-insensitively. Use a separate custom header agreed with your integration team.Identity propagation exampleSuppose the automation has a required Text input named callerIdentity. Set Provided by to System, Input source to HTTP header, Header name to X-Caller-Identity, and Fallback to None. Have the caller include these headers on its authenticated A2A message request:
X-Caller-Identity is an illustrative custom name, not a required Elementum or customer header. Use synthetic-identity-marker instead of a real downstream token for the first propagation test. The automation receives the complete custom header value, including Bearer when supplied. Configure its downstream request to use the agreed format without adding the prefix twice. The Authorization header authenticates the A2A call and is not the mapped input. Follow your agent’s configured A2A authentication method if it differs from this example.Missing, invalid, and fallback behavior
  • Missing means an absent or empty header, an absent metadata path, or a JSON null metadata value. Metadata false, 0, and empty strings are present values. A whitespace-only header is not treated as absent.
  • Values must match the automation parameter’s type and single/multiple shape. Metadata retains JSON types. Headers carry text: Boolean and numeric inputs require JSON such as false or 42; multiple-value inputs require a JSON array such as ["first", "second"]. Comma-separated text is not an array. Dates use YYYY-MM-DD; date-times require an ISO 8601 value with an offset; identifier inputs require valid UUIDs. Duplicate values for a mapped header are invalid.
  • An expired or fabricated OAuth token can still be a valid Text value. Binding does not verify token authenticity, expiry, audience, or scopes; the downstream service must validate authorization. A downstream rejection happens after the automation starts and does not trigger Agent fallback.
  • Missing context does not reject the entire incoming A2A message. Requiredness and type checks apply when the selected automation tool runs.
Security and lifetime
  • The configured value is captured for the current A2A request and reused across tool calls in that turn. Send it again on each follow-up request, including requests in the same conversation. The snapshot stays in memory for in-flight work; it is not saved as conversation context or restored after a process restart.
  • System binding keeps the value out of model prompts and model-facing tool arguments. It does not protect a value that your automation echoes in outputs, errors, records, or logs. Return only non-sensitive results and review downstream logging and retention.
  • A system source is caller-supplied data, not proof of identity. Authenticate the caller and control which identity values it can assert. Mapping an input does not change the tool’s execution permissions or grant downstream access.
  • These sources are incoming A2A request properties. Do not assume ordinary chat, voice, another tool type, or a delegated agent receives the same context automatically.
Validation checklistUse a test automation that records only a pass/fail comparison against a synthetic marker and returns a non-sensitive result. Send an A2A message that explicitly asks the agent to run this tool, and confirm an actual tool call occurred before interpreting the result.
  • Present: Supply the marker in the mapped header. Confirm the automation receives the exact value, including any prefix, while the model-facing arguments and reply contain no marker. Repeat with the two metadata sources if used, placing the marker at the selected root and pointer.
  • Missing: Omit the header, send an empty header, or omit/set the metadata path to null. Required + None must prevent this automation from starting; optional + None must omit the input. On a separate non-sensitive input, check that Agent fallback is available only when the source is missing.
  • Invalid: Use a Boolean or Number test input and supply not-a-number, the wrong JSON type, or the wrong single/multiple shape. Test duplicate mapped headers if the client supports them. Confirm no automation start and no Agent fallback. Test invalid or expired tokens separately against the downstream service; a Text binding alone cannot reject them.
  • Override attempts: With a present marker, ask the agent to replace the input with a different value. Confirm the automation still receives the marker. With required + None and no source, a value in the prompt must not satisfy the input. Integration tests that can inject unexpected model tool arguments should check the same precedence.
  • Next request and exposure: Run two tool calls in one turn, then a follow-up request without the source. The first two calls must use the same marker; the follow-up must follow missing-value rules. Confirm outputs, errors, transcripts, and retained test evidence contain no real credentials.

Automations: Original Email (.eml) on Email is Received Automations

The Email is Received trigger offers a new Triggered Email File value reference that saves the full received message—headers, body, metadata, and attachments—as a single message.eml file on a record using the Save Attachment action. Users can preview the saved .eml on the record details page to see the sender, recipients, date, subject, body, inline images, and attached file names without leaving Elementum.

Search Records by User’s Groups Automations

Automation builders can filter group fields in the Search Records action by the groups a specific user belongs to, including the Triggered By user on On Demand Triggers. A new User’s Groups value reference is available anywhere a user-type value reference can be used.

User Field: Field-Level Filtering Options Apps

App Admins can add a filter to any user-type field to limit which users can be selected, accepting any mix of individual users, groups, and up to one group field on the record. Only the combined set of eligible users appears when the field is filled out, and selections stay in sync as the referenced group field changes.

Data Entry Views: Aggregation Widgets Apps

App Admins can add up to three summary widgets above a Data Entry managed view to show running totals alongside the grid as users enter values. Each widget sums a numeric value from a filtered set of records on a table or aspect, sums an editable column across the visible rows, or combines two other widgets by adding or subtracting their totals.

User Field Filtering Apps

App Admins can add a filter to a user-type field that limits which users can be selected, accepting any mix of specific users, groups, and up to one group field on the record. The field displays only the combined set of eligible users—every selected user, every member of each selected group, and every member of the group currently stored in the selected group field—so form and record editors never see anyone outside the configured set.

Closed beta

These features are available to a limited set of customers by invitation and are not broadly available yet.
  • Elementum Development Kit (EDK) — A code-first toolkit for building Elementum in TypeScript as an alternative to building in the platform. Represent Apps, Elements, Automations, Agents, Skills, Flows, Search Tables, and Approval Chains as typed source, then follow a Terraform-like lifecycle: pull existing entities into a local workspace, author changes with typed @catalog references, preview a structural diff with plan, and apply approved changes. Packaged coding-agent playbooks teach AI coding agents the EDK’s conventions, so you can describe an outcome in plain language and delegate the authoring from your editor or CLI. Get started with the EDK documentation to install the toolchain, authenticate, and bootstrap an organization workspace.

Stay in the loop