Adding Data Service Objects & Sources

Q: My new record type returns "no mappings found." Why?

Your mapping rows must match both the record type and the exact data-source segment in the address you called. A source name mismatch is the usual cause — check that the rows and the endpoint use the same source.

Admin 8 min read Updated July 2026

The Data Service ships wired up for web inquiries, but the engine behind it is generic: you can point it at a different record type — web service requests, for example — or split two families of forms into separate sources, and it's all configuration. There's no code to write, just one permission row for the record type and one small mapping row per field. This article is the recipe. After reading it you'll be able to open a new record type to web intake, build its field mappings with defaults, choose a data-source name, and test the new connection safely before you point a live form at it. It assumes you've read Connect Your Forms, which explains the endpoint, the request shape, and authentication.

Getting there. The Data Service's permission rows and field mappings are administrator settings that live in your org's setup, alongside REDA's other configuration records — not inside the REDA apps themselves. Your administrator manages them the same way as REDA's other setup records.
Access you'll need. This is administrator work: you need the ability to manage your org's configuration records. No REDA permission set on its own grants it — it's an org-level administrator capability.

Never publish an API key. Every record type you open carries its own key — an environment-specific secret. Set a fresh key on each new Setup row, never reuse the demo key from a trial org, and keep real keys out of pages, repositories, and screenshots.

Using REDA Sales Cloud edition? This article shows the Platform edition, where maintenance and service requests are Service Request records (the standard Case). Everything else — the fields, the steps and the behaviour — is the same unless noted. See REDA editions.

The three building blocks

Configuring the Data Service means working with three kinds of record. The first is already done for you; the other two are what you'll build:

Building block	How many	Custom Metadata Type	What it does
Master switch	One, org-wide	`Data Service Config`	Turns the whole Data Service on. Already on in a working org — leave it alone.
Setup row	One per record type	`Data Service Setup`	Says which record type accepts intake and how: read/submit switches, Create Record and Edit Record switches, and the Auth Key that turns on authentication.
Mapping rows	One per field, per source	`Data Service Mapping`	Translates each request key into a field on the record, with an optional default value.

REDA processes the record from these rows exactly as it does for the shipped web integration: it applies each mapping's default first, overwrites with the values your form sent, and saves the record. If no mapping rows exist for the record type and source you called, REDA returns an error; if the save fails, the failure lands in the Async Log with the full payload. That behavior is inherited — you don't configure it.

Step 1 — Create or unlock the Setup row

The Setup row is what makes a record type reachable. For a brand-new record type, create a row for it; for a record type that ships parked (like the Service Request), unlock the row that's already there.

Name the record type. The row identifies which record type it governs; each record type gets exactly one Setup row.

Choose the operations. Turn on the request kinds you want — a submit request for forms — and the operations you'll allow: Create Record for new records, Edit Record if forms will update existing ones.

Set an Auth Key. Enter a fresh key. Once it's set, every request to this record type must carry a matching x-api-key header — the difference between a locked door and an open one.

Set an auth key on every internet-facing record type. The shipped Service Request row ships with every switch off — the safe parked state. Whenever you open a record type to the public web, give it a key before you turn its create switch on, so it's never reachable unauthenticated.

The public connection must be allowed to write the new record type. The endpoint is reached through the public web connection your administrator set up (the same one the shipped inquiry intake uses). That connection creates records as its own account — so for a brand-new record type, that account needs permission to create and edit it, and to write the fields your mappings target, exactly as it already does for inquiries. If a test submission is accepted but no record appears and the Async Log shows a permissions error, this is the usual cause. Confirm the connection's access with your administrator before pointing a live form at a new record type.

Step 2 — Name your data source

A data source is a label that groups one set of mappings. It's the last segment of the endpoint address, and it lets the same record type serve several different forms without their fields colliding. The shipped web inquiries use the source Web; you might use Web for your first form family and a campaign-specific name for another.

Pick a source name now — you'll stamp it on every mapping row in the next step, and your form will include it in the address it posts to. Use one source per form family: forms that send the same set of keys and want the same defaults share a source; forms that need a different key set or different defaults get their own.

Step 3 — Build the mapping rows

Now translate each form field into a REDA field. Add one mapping row per field, each carrying:

On each mapping row	What you set
Data source	The source name you chose in Step 2 — must match the address exactly.
Record type	The same record type as the Setup row.
Request key	The key your form sends (for example, `subject`).
Target field	The REDA field it fills.
Default value (optional)	A value used when the form omits that key — handy for stamping provenance.

Two patterns are worth knowing. Use defaults for provenance — the shipped web set, for instance, defaults the source of the inquiry to Web so every web-created record is labelled at birth. And add a recordId mapping only if you want web-side updates: map recordId to the record's identifier, and pair it with Edit Record on the Setup row. Without that mapping, every submission creates a new record.

Test any date, number, or picklist field before you rely on it. The values your form sends arrive as text and are placed onto the record's fields. Plain text fields are straightforward; for a date, number, or picklist target, send a real sample through Step 4 and confirm it lands correctly before pointing a live form at it — a value the field can't accept surfaces in the Async Log rather than saving.

Step 4 — Test

Before you point a live form at the new connection, send it a test request yourself:

Post the key/value array to .../dataservice/<Record Type>/<Your Source> with the x-api-key header carrying your new key.

Confirm the record. A successful reply is followed a moment later by the new record — open it and check the fields landed where your mappings say they should.

Force a failure. Send a request that omits a required field, then find the resulting entry in the Async Log — confirming that when a real form misfires, you'll be able to see exactly what it sent.

Worked example: a "report an issue" form

Meridian Properties wants a public "report an issue" form on its marketing site — separate from the authenticated request flow inside the resident portal — that creates a REDA Service Request. Because the Service Request Setup row already ships parked, the recipe is short:

Step	What Meridian does
Unlock the Setup row	Turn on the submit request and Create Record on the Service Request row; set a fresh auth key.
Name the source	Use `Web` for this form family.
Add mappings	Map the form's `subject`, `description`, and reporter `email` keys to the matching service-request fields, and add a default that stamps the source as web.
Test	Post a sample; a service request appears. Post one missing a required field; an Async Log entry appears with the payload.

The live form now files service requests straight into REDA, and the marketing site's public form stays entirely separate from the portal's authenticated one.

Where to go next

REDA Data Service: Connect Your Forms — the engine, the endpoint, and the shipped web-inquiry set.
Understanding REDA Async Logs — where failed submissions land, and how to triage them.
Web Inquiries & Tour Requests — the shipped inquiry intake this recipe generalizes.

Frequently asked questions

Your mapping rows must match both the record type and the exact data-source segment in the address you called. A source name mismatch is the usual cause — check that the rows and the endpoint use the same source.

No — keys live on each record type's Setup row, one per row. Set a separate key for each. Independent keys are the point: you can rotate one without disturbing the others.

No. The record type's own validation rules apply when the record is saved, exactly as they do for a record created by hand. A submission that fails a rule doesn't create a record — it lands in the Async Log with the payload.

Both pass the same gate, but forms should submit (POST) — that's the request kind that carries a body of field values. Reads are for retrieving, not creating.

Was this article helpful?