Tag: FileMaker

AI in FileMaker should start with workflow, not novelty

AI features are becoming part of FileMaker development, but the best use cases aren’t random chat boxes in a layout.

The better question is: where can AI reduce friction in a real workflow?

That might mean helping users summarize notes, classify requests, search by meaning instead of keywords, draft responses, or extract useful structure from messy text. FileMaker’s newer AI script steps support several of these patterns, including getting text responses from models, using natural language with database schema, generating SQL, performing AI-assisted finds, creating embeddings, using retrieval-augmented generation, and controlling AI call logging.

The opportunity is real, but so is the risk. AI should support the workflow, not silently become the workflow.

Start with a narrow, reviewable use case

A good first AI workflow should be narrow and easy to verify.

Good candidates include:

• Summarize a long service note
• Classify an incoming request
• Draft a follow-up email
• Suggest a priority level
• Search historical records by meaning
• Extract action items from meeting notes

Poor first candidates include:

• Automatically approve requests
• Overwrite important records
• Make financial decisions
• Update multiple related records without review
• Replace established validation logic

The safest early pattern is “AI suggests, user confirms.”

Configure the AI account deliberately

FileMaker’s AI script steps rely on configured AI accounts. For example, Claris documents that steps such as Insert Embedding and Perform Semantic Find require a named AI account to be configured in the file before those steps run.

That means AI should be treated like an integration, not like a casual layout feature.

At minimum, define:

AI account name

model or service being used

which scripts can call it

what data may be sent

where results will be stored

whether calls should be logged

This matters because AI workflows often touch sensitive business context. You want to know which data is being sent, why it is being sent, and where the result goes.

Pattern 1: Summarize long notes into a clean internal brief

One practical workflow is note summarization.

Imagine a service team that records long visit notes. Managers may not have time to read every detail, but they need the key points.

A FileMaker-assisted AI flow could look like this:

User writes or imports service notes

   ↓

User clicks “Generate Summary”

   ↓

FileMaker sends selected note text to AI

   ↓

AI returns a concise summary

   ↓

Summary is stored in a review field

   ↓

User edits or approves the result

The key is that the AI output should land in a separate field first.

For example:

ServiceNotes::RawNotes

ServiceNotes::AISummaryDraft

ServiceNotes::FinalSummary

ServiceNotes::SummaryReviewedBy

ServiceNotes::SummaryReviewedAt

This preserves the source note and gives the user a place to review the AI result before it becomes part of the official record.

Pattern 2: Classify incoming requests

AI can also help sort messy intake records.

For example, an incoming request might need to be classified as:

• billing
• support
• operations
• sales
• urgent issue
• general question

The script should not blindly accept the AI output. A stronger pattern is:

AI returns suggested category

AI returns confidence or reasoning

FileMaker stores result as a suggestion

User confirms or changes category

Confirmed value drives workflow

A field structure might look like:

Request::SubmittedText

Request::AISuggestedCategory

Request::AISuggestedPriority

Request::AIReason

Request::FinalCategory

Request::FinalPriority

Request::ReviewedBy

This makes AI useful without letting it quietly control routing on its own.

Pattern 3: Semantic search across FileMaker records

One of the more interesting FileMaker AI patterns is semantic search.

Traditional FileMaker find is exact or structured. Semantic search lets users find records based on meaning. Claris documents script steps for inserting embedding vectors into records or found sets, then performing semantic finds against that embedded data.

That can be useful when users search for concepts rather than exact words.

For example, a user might search:

“customers who complained about late shipments”

Even if the records do not use that exact phrase, semantic search may help find records with similar meaning.

A practical architecture looks like this:

Source text field

   ↓

Embedding generated and stored

   ↓

User enters natural language search

   ↓

FileMaker performs semantic find

   ↓

Results are reviewed by user

This can be especially useful for notes, support tickets, case histories, knowledge bases, and project descriptions.

Keep AI outputs separate from approved data

This is one of the most important design rules.

Do not overwrite important user-entered or business-critical fields directly with AI output.

Instead, use a staged field pattern:

OriginalValue

AISuggestedValue

FinalApprovedValue

ReviewedBy

ReviewedAt

This gives the workflow a human checkpoint and makes the system easier to audit.

It also makes users more comfortable. People are more likely to trust an AI-assisted workflow when they can see, edit, and approve the result.

Prompt design belongs in the system, not in the user’s memory

If a workflow depends on users typing the “right” prompt each time, the workflow is fragile.

FileMaker can help by storing prompt templates and using structured script logic to assemble prompts consistently. Claris’s AI script step documentation includes support for setting up prompt templates for use in other AI script steps.

A simple prompt template might include:

You are assisting with service request triage.

Classify the request into one of these categories:

– Billing

– Technical Support

– Operations

– Sales

– Other

Return JSON with:

category

priority

summary

reason

Request text:

<<REQUEST_TEXT>>

Asking for structured output, such as JSON, can make the result easier to parse and store in FileMaker.

Add guardrails for sensitive workflows

AI-assisted features should be more restricted when they touch sensitive data.

Useful guardrails include:

• Require user confirmation before saving AI output
• Log AI requests and responses where appropriate
• Avoid sending unnecessary fields
• Do not expose privileged data through broad prompts
• Separate draft fields from approved fields
• Show users when content was AI-generated
• Provide a fallback manual workflow

FileMaker’s AI features give developers powerful tools, but the application still needs a governance model.

Where AI-assisted FileMaker workflows fit best

Good fits include:

• Summarization
• Classification
• Search
• Drafting
• Extracting action items
• Generating first-pass descriptions
• Finding similar records

Riskier fits include:

• Approvals
• Financial decisions
• Compliance determinations
• Irreversible updates
• Complex business-rule execution

The closer the workflow gets to a business decision, the more human review matters.

Final thought

The best AI features in FileMaker will probably not feel like “AI features.”

They will feel like smoother workflows.

A user clicks a button and gets a clean summary.
A manager finds relevant records faster.
A team triages messy requests with less manual effort.

That is the right bar: AI should reduce friction while FileMaker remains the system that structures, governs, and records the work.

FileMaker data is becoming more accessible to AI workflows

For years, connecting FileMaker to external tools usually meant building integrations through APIs, middleware, custom scripts, or third-party services.

Claris MCP introduces a different pattern.

Claris describes MCP as a server that connects FileMaker databases to AI assistants and other MCP-compatible hosts. It acts as a bridge between Claris data and AI tools, letting you create connections, select tables and scripts, configure database tools, and generate configuration snippets for integration.

That makes it one of the more important recent developments for FileMaker teams exploring AI.

What MCP changes conceptually

The traditional integration question is:

“How do we build an API so another system can use FileMaker data?”

The MCP question is different:

“What tools should an AI assistant be allowed to use against this FileMaker system?”

That is a major shift.

Instead of exposing everything, you define controlled capabilities. Those capabilities may include access to selected tables, selected fields, and selected scripts.

That creates a more practical and safer path for AI-assisted work.

A simple architecture

A basic Claris MCP setup looks like this:

AI assistant or MCP-compatible client

       ↓

Claris MCP server

       ↓

Configured FileMaker connection

       ↓

Selected tables, fields, and scripts

       ↓

FileMaker database

The key point is that MCP is not magic access to everything. It is a configured bridge.

Claris’s getting started documentation describes the basic flow as creating a context, adding a connection to your FileMaker database, and generating a configuration snippet for the AI client.

Start with a read-only use case

The safest first use case is not “let AI update my database.”

A better first use case is controlled query and analysis.

For example:

• summarize open support cases
• find overdue project tasks
• list customers with upcoming renewals
• answer questions about current inventory
• retrieve recent activity for a client
• summarize records matching a specific condition

This lets the team learn how MCP behaves without giving the assistant permission to make operational changes too early.

Choose the right tables and fields

The most important implementation decision is what to expose.

Do not start by exposing the whole database. Start with a narrow business question.

For example, if the goal is to let an assistant answer questions about open service tickets, the MCP-accessible data might be limited to:

Tickets

– TicketID

– CustomerName

– Status

– Priority

– CreatedDate

– DueDate

– AssignedTo

– Summary

TicketNotes

– TicketID

– NoteDate

– NoteAuthor

– NoteText

You may not need billing fields, internal margin data, private employee notes, or unrelated customer tables.

Claris notes that FileMaker file accounts need access to the connected tables and fields intended to be available to the MCP client.

That means standard FileMaker privilege design still matters.

Use scripts as controlled actions

Tables let an assistant retrieve data. Scripts can let it do work.

This is where MCP becomes powerful, but also where discipline matters.

Instead of exposing broad write access, expose carefully designed scripts that perform specific operations.

For example:

Get Customer Renewal Summary

Create Follow-Up Task

Mark Ticket as Ready for Review

Add Note to Project

Generate Open Issues Report

Each script should validate its inputs, enforce business rules, and return clear results.

A good MCP-facing script should behave like a small internal API endpoint:

Input: structured JSON

Process: validate, act, log

Output: structured JSON result

That makes the AI assistant easier to control because it can only take actions through scripts you intentionally provide.

Privileges and extended privileges matter

MCP is not a reason to ignore FileMaker security. It depends on it.

Claris documents that accounts used for MCP connections must have both fmrest and fmodata extended privileges enabled. It also notes that field access must be available for the tables and fields you intend to expose.

That means MCP setup should involve a dedicated privilege set, not a full-access developer account.

A practical starting approach:

Create a dedicated MCP account

Create a dedicated privilege set

Expose only required layouts, tables, and fields

Enable only required extended privileges

Limit scripts to MCP-safe operations

Test with read-only workflows first

This keeps the integration more controlled.

Be careful with value lists on FileMaker Server 22.0.2

Claris notes a system limitation in FileMaker Server 22.0.2 where value list access should be disabled to prevent errors with the MCP connection.

That kind of detail matters in a real setup guide because it can save developers from chasing confusing connection issues.

Generate and use the client configuration

After configuring the MCP context and connection, Claris MCP can generate a configuration snippet for the MCP client. Claris’s integration documentation says you copy the JSON configuration and paste it into the MCP client settings so the assistant can access FileMaker data through the configured tools.

A typical implementation flow looks like this:

1. Install and configure Claris MCP
2. Create a context
3. Add a FileMaker database connection
4. Select approved tables and scripts
5. Generate the MCP configuration snippet
6. Add the snippet to the MCP-compatible AI client
7. Test with low-risk prompts
8. Review logs, permissions, and returned results

The important part is not the snippet itself. It is the preparation before the snippet is generated.

Design prompts around allowed tools

Once MCP is configured, users may be able to ask natural-language questions that invoke the configured tools.

For example:

Show me all open high-priority tickets assigned to Mark.

or:

Summarize overdue renewal follow-ups for this week.

For action-oriented workflows, keep prompts clear and constrained:

Create a follow-up task for customer ABC Manufacturing about their renewal.

But again, the assistant should only be able to do this if you exposed a safe script for creating follow-up tasks.

Add logging and review

AI-assisted access to FileMaker should be observable.

For any MCP-enabled workflow, consider logging:

• Who used the assistant
• What tool was called
• What inputs were passed
• What script ran
• What record was affected
• Whether the action succeeded or failed

This is especially important once you allow script-based actions.

A good internal log table might include:

MCPLog

– LogID

– Timestamp

– User

– ToolName

– InputJSON

– ResultJSON

– RelatedRecordID

– Status

That gives administrators a way to review behavior and troubleshoot unexpected results.

Where Claris MCP fits best

Good early use cases include:

• Internal data lookup
• Operational summaries
• Task creation through controlled scripts
• Customer or project brief generation
• Support case review
• Management reporting prompts

Riskier use cases include:

• Financial updates
• Compliance decisions
• Mass record changes
• Anything involving sensitive data without strict privilege design
• Any action that bypasses existing FileMaker validation

MCP is strongest when it gives AI a controlled way to interact with FileMaker, not when it opens the database broadly.

Final thought

Claris MCP is not just another integration option. It changes the interface between FileMaker and AI systems.

Instead of building one-off API endpoints for every assistant-driven use case, developers can expose selected FileMaker data and scripts as controlled tools.

That is powerful, but it should be approached carefully.

Start read-only.
Expose less than you think you need.
Use scripts for controlled actions.
Keep FileMaker privileges tight.
Log what the assistant does.

That is how MCP becomes useful without turning into a governance problem.

FileMaker does not have to do every job by itself

FileMaker is excellent at managing business logic, structured data, custom workflows, and internal operations. But many modern workflows do not remain within a single system.

A record gets created in FileMaker, then someone needs an email notification. A customer status changes, then another system needs to know. Once a request is approved, a document, message, task, or external update needs to be created elsewhere.

That is where Claris Connect becomes useful.

Rather than treating FileMaker as the place where every integration and automation must be hand-built, you can use Claris Connect as a workflow engine around your FileMaker solution.

What Claris Connect adds to FileMaker

Claris Connect lets you build flows that connect FileMaker with other applications and services. The Claris FileMaker connector works with hosted FileMaker apps, including FileMaker Cloud and FileMaker Server 21.1.0 or later.

That means FileMaker can remain the system of record while Connect handles the surrounding automation.

A useful way to think about the architecture is:

FileMaker

– source data

– business rules

– scripts

– approvals

       ↓

Claris Connect

– triggers

– routing

– notifications

– external app updates

       ↓

Other systems

– email

– Slack or Teams

– CRM

– project management

– spreadsheets

– web services

This keeps FileMaker focused on the core business process while Connect handles the movement around it.

Start with the event that should trigger the workflow

A good Connect workflow starts with a clear event.

For example:

• a new request is created
• an invoice is marked approved
• a support case changes status
• a project enters a new phase
• a client record is updated
• a renewal date is approaching

The goal is not to automate everything. The goal is to identify the moments where FileMaker data should cause something else to happen.

Claris documents that FileMaker and Studio connectors can trigger Connect flows, and that a FileMaker script can send JSON data to Claris Connect. That script can be run manually or through a script trigger such as OnRecordCommit.

Use FileMaker scripts to send clean JSON

A reliable workflow depends on sending the right payload to Connect.

Instead of sending loose text values, use JSON. That makes the flow easier to read, debug, and extend.

Example:

{

 “event”: “invoice_approved”,

 “invoiceID”: “INV-1045”,

 “customerID”: “CUST-2221”,

 “customerName”: “Example Manufacturing”,

 “approvedBy”: “jane@example.com”,

 “approvedAt”: “2026-05-12 10:45:00”,

 “amount”: 12850.00

}

In FileMaker, that might be assembled using JSONSetElement and then passed to Connect via the Trigger Claris Connect Flow script step.

Claris notes that the Trigger Claris Connect Flow script step automates triggering a Connect flow using a webhook. It can also be used while a flow is inactive to test whether the trigger is receiving data before enabling the full flow.

Keep FileMaker responsible for business logic

Connect is useful for orchestration. It should not become a hidden replacement for your FileMaker business logic.

A good boundary is:

FileMaker decides what happened.
Connect decides what happens next.

For example, FileMaker should determine whether an invoice is truly approved. Connect can then send a notification, create a task, update another app, or call an external API.

That separation makes your process easier to audit and maintain.

Build the flow in small, named steps

A practical Connect flow should be easy to follow.

For an approved invoice workflow, the flow might look like this:

Trigger: FileMaker sends invoice approval event

   ↓

Validate required JSON values

   ↓

Find customer in CRM

   ↓

Send approval notification

   ↓

Create accounting follow-up task

   ↓

Write confirmation back to FileMaker

That last step matters. Whenever possible, write the result back to FileMaker so the system of record knows whether the automation succeeded.

A good FileMaker field pattern might include:

AutomationStatus

AutomationLastRunAt

AutomationLastResult

AutomationErrorMessage

This makes the workflow visible instead of mysterious.

Design for failure from the beginning

Automation will eventually fail.

A missing email address, an inactive external account, a bad API response, a permission issue, or a malformed payload can break a flow. That is not a reason to avoid automation. It is a reason to clearly design for failure.

At a minimum, a FileMaker-connected workflow should track:

• When the event was sent
• Whether Connect received it
• Whether the flow is completed
• What error was returned
• Whether the event can be retried safely

This is especially important when a flow performs external actions, such as sending messages or creating records in another system.

Make flows idempotent where possible

A workflow is idempotent when running it more than once does not create duplicate damage.

For example, if a FileMaker script sends the same “invoice approved” event twice, the Connect flow should avoid creating two identical tasks or sending two conflicting updates, if possible.

A few practical ways to support this:

• Include a stable event ID in the JSON payload
• Store the external record ID after creation
• Check for an existing task before creating a new one
• Write completion status back to FileMaker
• Separate “sent” from “completed”

This is the difference between a demo automation and a production-ready workflow.

Where this pattern works best

Claris Connect is a strong fit for FileMaker when it needs to coordinate with other systems.

Good use cases include:

• customer onboarding notifications
• invoice approval workflows
• support ticket routing
• task creation after status changes
• syncing key records to another system
• scheduled follow-ups
• external alerts or reminders

It is less ideal when the work is entirely internal to FileMaker, requires complex multi-record transactions, or depends on very high-frequency record changes.

A practical implementation checklist

Before building a Connect workflow around FileMaker, define:

1. What FileMaker event should start the flow?
2. What JSON payload should be sent?
3. Which system owns the business decision?
4. What should Connect do after the event?
5. What should be written back to FileMaker?
6. How will errors be logged?
7. Can the flow be retried safely?

That checklist helps keep the automation grounded.

Final thought

The best use of Claris Connect is not to make FileMaker less important.

It is to let FileMaker stay focused on what it does best, while Connect handles the surrounding movement between systems.

That is the modern Claris architecture: FileMaker as the operational core, Connect as the workflow engine around it.