Keep up to date with the latest news and thought leadership.
Teams often ask for “an online form,” but that usually isn’t what they truly need.
What they really need is a workflow that collects information, checks it, sends it to the right place, adds details, updates records, and shows the current status to the right people.
This is why Claris Studio stands out when you see it as more than just a web form tool. You can share Studio forms with your team or anyone who has the link. Claris presents Studio as a platform for collecting, viewing, and analyzing data, which can also be used in custom apps.
For many implementations, the strongest pattern is:
Vendor onboarding is a good example because it has all the right ingredients:
That makes it better than a trivial demo.
Here is the core pattern:
External submitter
↓
Claris Studio form
↓
Claris Connect flow
↓
FileMaker
– validation
– dedupe
– vendor creation or update
– review tasks
– status management
↓
Claris Studio views/hubs
– intake queue
– review queue
– status visibility
This setup works well because Studio is great for easy, web-based data capture, while FileMaker is better for handling records and enforcing processes. Connect links the two when you need to move, change, or automate data.
Before building anything, decide where the real record begins.
Model 1: FileMaker-first
The Studio form writes into a FileMaker-connected data source, and FileMaker is the source of truth from the start.
Model 2: Studio-first, then promoted to FileMaker
The Studio form creates a Studio-side record first, and Connect later transforms that submission into operational records in FileMaker.
Both models can work. However, if your workflow involves important business data like vendors, clients, orders, or compliance records, starting with FileMaker is usually the safer choice for the long term.
Claris Connect can be useful here, but the boundaries matter.
The Claris FileMaker connector works with hosted FileMaker apps and requires at least FileMaker Cloud or FileMaker Server 21.1.0. Claris also points out that the connector does not yet support direct access to Claris Studio tables. So, you should not expect one connector to handle every type of data in the same way.
Claris also documents that when working with FileMaker through Connect, the target app must have both Data API and OData privileges enabled, and those services must also be enabled on the host.
Details like this are important to highlight in a real implementation guide.
A common mistake is building the intake form first and only later figuring out how the data fits into the system.
It’s better to define the operational schema before anything else. For a vendor onboarding workflow, a basic structure might be:
Intake_Request
– RequestUUID
– SubmittedAt
– SubmittedByName
– SubmittedByEmail
– CompanyNameRaw
– TaxIDRaw
– RequestType
– RawPayloadJSON
– ProcessingStatus
– ProcessingError
– RelatedVendorUUID
Vendor
– VendorUUID
– LegalName
– NormalizedTaxID
– PrimaryEmail
– Status
– CreatedAt
VendorContact
– ContactUUID
– VendorUUID
– FullName
– Phone
ReviewTask
– TaskUUID
– RequestUUID
– AssignedTo
– TaskType
– TaskStatus
– DueDate
StatusHistory
– HistoryUUID
– RequestUUID
– OldStatus
– NewStatus
– ChangedAt
– ChangedBy
Two fields here matter more than they may seem:
RawPayloadJSON gives you an audit-safe copy of exactly what came in.
ProcessingStatus and ProcessingError help you track the workflow, which is important when something goes wrong.
Once you have the schema, designing the form gets easier.
A good intake form doesn’t try to gather every detail. It collects just enough clean information to start the process, leaving space to add more details later if needed.
That usually means:
Studio forms can be shared broadly, including with anonymous users via a link, which is why form discipline matters.
Here is the shape of a practical flow:
Trigger: New intake record created
↓
Validate required fields
↓
Normalize values
– trim whitespace
– normalize email case
– strip punctuation from tax ID
↓
Check for existing vendor
↓
If vendor exists:
update/attach to existing
Else:
Create new vendor
Create primary contact
Create review task
↓
Write result back to intake record
– processed
– needs review
– duplicate found
– error
The real technical value isn’t in the visual flow, but in clearly separating each step.
Validation is not the same as normalization.
Normalization is not the same as deduplication.
Deduplication is not the same as approval.
The clearer you make these boundaries, the more reliable your workflow will be.
When Connect or another process hands work to FileMaker, JSON parameters are usually cleaner than trying to overload single text parameters.
For example:
{
“requestUUID”: “2C8A0A6E-85A3-4C3C-A8C0-41F9A88D4E10”,
“submittedByEmail”: “ap@vendorco.com”,
“requestType”: “New Vendor”,
“source”: “Claris Studio”
}
Then the receiving FileMaker script can parse predictably:
Set Variable [ $requestUUID ; JSONGetElement ( Get ( ScriptParameter ) ; “requestUUID” ) ]
Set Variable [ $email ; JSONGetElement ( Get ( ScriptParameter ) ; “submittedByEmail” ) ]
Set Variable [ $type ; JSONGetElement ( Get ( ScriptParameter ) ; “requestType” ) ]
Set Variable [ $source ; JSONGetElement ( Get ( ScriptParameter ) ; “source” ) ]
This isn’t advanced code, but it’s a reliable habit for implementation.
Relying only on exact matches is rarely enough for intake workflows.
A more useful pattern is to check some combination of:
This approach helps you handle different outcomes more effectively:
This is where FileMaker really proves its value. When cross-record logic is important, it’s best to keep the decision-making in the FileMaker app.
This is one of the most practical lessons to include because many “working” intake flows fail here.
Never assume a submission is processed exactly once.
A safer design includes:
That way, if a flow retries or a user resubmits, the system can recognize the event without creating a mess.
Once the workflow runs, Studio becomes useful again as the visibility layer.
You can create views or hubs that show:
That creates a much better operational surface than an email chain or a spreadsheet export.
If you are using Connect with FileMaker, Claris documents that both Data API and OData access must be enabled appropriately. OData is a REST-based standard for querying and updating hosted FileMaker data, and the general OData workflow includes finding and modifying records, as well as running FileMaker scripts via API calls.
That does not mean every intake workflow should become an API-heavy project. It means your architecture should be intentional about privileges and integration points.
The right way to frame a Studio intake project is not, “How do we put a form on the web?”
It is, “How do we build a reliable intake pipeline?”
Studio gives you a clean web-facing start.
FileMaker gives you durable logic and operational control.
Connect gives you orchestration when the workflow needs to move, transform, or notify.
That is the version readers can actually implement.
Let’s talk about how we can help you streamline, scale, or innovate—on your terms.
Start the Conversation
