Elements.cloud

Elements.cloud is the change-intelligence platform for Salesforce teams. Workflows create, update, and list Stories and Requirements in the backlog, with statuses and custom fields, so change requests stay in sync with the systems that raise them.

Verified 14 actions API key available

Elements.cloud website Platform Documentation Capability data verified 2026-08-25

A Salesforce change request arrives from the intake form the operations team publishes

Agent reads what the requester wants changed, who is asking, and why they say it matters

List Requirement Statuses and List Requirement Custom Fields resolve this Space's own vocabulary before anything is written

List Requirements looks for an existing requirement that already covers the same change

The agent drafts What Is Required, Required By, and Required By Reason and puts the draft in front of the platform owner

The platform owner confirms or rewrites the business justification, and only then does Create Requirement file it

What This Integration Enables

Elements.cloud is not a backlog tool that happens to serve Salesforce teams. It exists to answer a question a backlog tool cannot: why does this change exist, and what does it touch. That is why Requirements and Stories are separate objects with separate status sets and separate custom field definitions, and why the fields the product cares about most are the ones describing the need rather than the work. FlowRunner agents read and write both objects, resolve each Space's own statuses and custom fields before writing, and carry an External ID so a story in Elements and a ticket in the system that raised it can be matched later without either side keeping a mapping table.

The design constraint worth planning around is the quota. Elements allows a fixed number of API requests per month per Space, and the limit applies to the Space rather than to your token, so a chatty integration throttles everyone else's. A polling loop is therefore the wrong architecture here, not merely an inefficient one. FlowRunner agents run this connector event-first: a webhook configured in the Elements Space Management portal points at a webhook-triggered flow, and the connector's read operations are used to hydrate context on demand rather than to discover that something changed. What stays with a person is the judgment the record is supposed to carry, which is where the human-in-the-loop gate below sits.

Without FlowRunner

Change requests arrive as prose A Slack message or an email asking for a field, with no record of who needed it or why

Traceability rebuilt after the fact Nobody can say which requirement a delivered story was meant to satisfy

Intake competes with delivery Whoever owns the org triages requests between actual build work

With FlowRunner

Change requests arrive as records Each one lands as a requirement with a stated need, a requester, and a reason

Traceability written at intake The story is created against the requirement that justified it, in the same run

Triage narrowed to judgment The agent handles matching, deduplication, and drafting, and the owner rules on the justification

Use Case Scenarios

Intake that produces a traceable requirement

A business user files a change request through a form in Jotform or Typeform, or opens a ticket in Zendesk. The agent classifies it, calls List Requirements to check whether an open requirement already covers the same need, and if not, assembles a draft: what is required, who requires it, and the reason. It resolves the target status with List Requirement Statuses and the field keys with List Requirement Custom Fields, because both are defined per Space and a value copied from anywhere else is rejected. The platform owner approves the draft, Create Requirement files it, and the requester gets a link back to a record rather than a promise in a thread.
Backlog kept in step with the delivery tracker

Delivery happens in Linear or GitHub, while the change record lives in Elements. The agent creates each story with the delivery tool's key in the External ID field, which is what lets a later flow reconcile the two without a mapping table. When a delivery item moves, the flow calls Get Story to read the current record, then Update Story with the full field set rather than a partial patch, because Elements documents omission behavior for one field only and an agent should not guess at the rest. Status changes resolve against List Story Statuses so the write uses a value this Space actually has.
A weekly view of change nobody has to assemble

Once a week the agent pulls open requirements and their linked stories, groups them by status and by requester, and posts a digest to the platform team in Slack with the ones that have sat in the same status longest called out. Because the read runs once a week rather than once a minute, it costs the Space a handful of requests instead of thousands, and the team gets a picture of change pressure that is current without anyone opening the tool.

Human-in-Loop Highlight

The field that matters most in this connector is not a status or an ID. It is Required By Reason on Create Requirement, the business justification that Elements exists to capture and that an audit, a release review, or a future architect will read years later to understand why the org looks the way it does. An agent can infer a plausible reason from an intake ticket. It cannot know whether the reason is the real one, and a confidently worded guess is worse than a blank field because it will be believed. So the intake agent drafts and stops: "Requirement drafted from ticket SUP-4182. What Is Required: a Renewal Risk picklist on Opportunity. Required By: Customer Success. Required By Reason drafted as 'to flag at-risk renewals in forecast reviews.' Confirm, edit, or reject." The platform owner rules on the justification, and the agent files it exactly as approved. The second gate follows the same logic in reverse: Delete Requirement and Delete Story are irreversible, and they take the link between requirement and story with them, which is precisely the traceability the product was bought for. Moving a record to a closed status is what a cleanup flow does instead, unless a person says otherwise.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

14 actions

Stories

List Stories Returns the Space's stories with filtering. Used for reporting and reconciliation on a schedule, not for change detection, since the Space's monthly request quota is shared by every token in it.
Get Story Returns one story with its custom field values. Used to read current state before an update, since the update is a full write rather than a patch.
Create Story Creates a story. External ID is the field that makes a two-way sync possible: put the delivery tool's key there and a later flow can match the two records without a mapping table.
Update Story Changes a story. Agents read the record first and send back everything they intend to keep, and leave the creator field alone unless reassigning the story is genuinely the intent.
Delete Story Permanently deletes a story, and any requirement that pointed at it loses that link. Gated behind a person, with a status change as the usual alternative.
List Story Statuses Returns the story statuses configured in this Space. Called before any status write, because statuses are per Space and a borrowed value is rejected.
List Story Custom Fields Returns the custom field definitions for stories in this Space. The only way to learn which keys a write may use.

Requirements

List Requirements Returns the Space's requirements. Used to check for an existing requirement covering the same need before filing a new one.
Get Requirement Returns one requirement with its custom field values. Used to gather full context before an update or a decision.
Create Requirement Files a requirement. What Is Required, Required By, and Required By Reason are the fields that turn an intake message into traceable change, and they are the reason this operation waits for a person.
Update Requirement Changes a requirement. Like the story update, it replaces rather than patches, so agents read first and send back the full field set.
Delete Requirement Permanently deletes a requirement, and every story linked to it loses the link. Reserved for a person's decision.
List Requirement Statuses Returns the requirement statuses configured in this Space. A separate set from the story statuses, and the two are not interchangeable.
List Requirement Custom Fields Returns the custom field definitions for requirements in this Space. Separate from the story custom fields, and read before any write that touches them.

Frequently Asked Questions

What can FlowRunner do with Elements.cloud?

FlowRunner agents can run List Stories, Get Story, and Create Story in Elements.cloud, plus 11 more actions.

Does connecting Elements.cloud to FlowRunner require OAuth?

No. Elements.cloud connects to FlowRunner with an API key, no OAuth flow required.

Can Elements.cloud trigger a FlowRunner workflow automatically?

Elements.cloud doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Elements.cloud

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us