Category: FileMaker

A dashboard is one of the most useful FileMaker modernization projects because it often uses existing data.

The challenge is not usually whether the data is available. The challenge is organizing that data into a view that helps people make decisions.

In this guide, we will walk through a practical approach to building an operational dashboard in FileMaker. The example is a manufacturing dashboard, but the same pattern can apply to service teams, sales operations, project management, inventory, fulfillment, or internal administration.

What We Are Building

The goal is to create a dashboard that helps a team quickly answer questions like:

• Which jobs are behind schedule?
• Which materials are causing production delays?
• Which orders are at risk of missing delivery dates?
• Which quality issues need attention?
• How much work is moving through each department?

This should not be just a screen full of charts. A useful dashboard should help users decide what to do next.

Step 1: Define the Decisions First

Before creating fields, charts, or layouts, define the business decisions the dashboard should support.

For example:

• What needs attention today?
• Which jobs are at risk?
• Which department is falling behind?
• Which orders may affect customers?
• What should a manager review first?

This matters because a dashboard can easily become cluttered. If a metric does not help someone make a decision, it may not belong on the first version.

For a first version, choose three to five high-value metrics.

Example:

• Late Jobs
• At-Risk Orders
• Open Quality Issues
• Material Shortages
• Throughput This Week
  
  

Step 2: Identify the Source Tables

Next, map each metric to the FileMaker tables and fields that already contain the data.

A manufacturing dashboard might involve tables like:

Jobs table:

• __pkJobID
• JobNumber
• CustomerID
• DepartmentID
• Status
• Priority
• StartDate
• TargetShipDate
• CompletedDate
• QtyRequired
• QtyCompleted

Orders table:

• __pkOrderID
• OrderNumber
• CustomerID
• PromiseDate
• Status

Materials table:

• __pkMaterialID
• PartNumber
• MaterialName
• QtyOnHand
• QtyCommitted
• ReorderPoint

JobMaterials table:

• __pkJobMaterialID
• JobID
• MaterialID
• QtyRequired
• QtyIssued

QualityIssues table:

• __pkQualityIssueID
• JobID
• Severity
• Status
• CreatedDate
• ResolvedDate

ProductionLog table:

• __pkProductionLogID
• JobID
• DepartmentID
• WorkDate
• CompletedQty
• LaborHours

You may not need all of these tables for the first version. Start with the data required to answer the most important questions.

Step 3: Add Useful Calculation Fields

Some dashboard logic can be handled with calculation fields in the source tables.

For example, in the Jobs table:

cIsLate

Returns true when the job is not complete and the target ship date is before today.

Plain-English logic:

Status is not “Complete”

and TargetShipDate is before today

cDaysLate

Returns the number of days between today and the target ship date.

Plain-English logic:

Today – TargetShipDate

cIsAtRisk

Returns true when the job is not late yet, but is close to the target date and still incomplete.

Plain-English logic:

Status is not “Complete”

and TargetShipDate is within the next few days

and QtyCompleted is less than QtyRequired

In the JobMaterials table, you may create:

cShortQty

Plain-English logic:

QtyRequired – QtyIssued

Depending on your data model, you may also need to account for available inventory, committed inventory, or material already allocated to other jobs.

The point is not to overbuild calculations. The point is to make dashboard logic easier to reuse and easier to understand.

Step 4: Decide Between Live Reporting and a Dashboard Cache

There are two common ways to build a FileMaker dashboard.

Option 1: Live reporting from source tables

This approach uses found sets, portals, summary fields, subsummary reports, and charts directly against live data.

This can work well when:

• The dashboard is simple
• The data volume is manageable
• Metrics come from one primary table
• Users need real-time visibility
• Performance is acceptable

Option 2: A dashboard cache table

This approach uses scripts to calculate dashboard metrics and write them into dedicated dashboard tables.

This can work better when:

• Metrics come from multiple tables
• The dashboard needs several unrelated KPIs
• Performance matters
• Users need consistent snapshots
• You want cleaner drilldowns and alert lists

For many operational dashboards, the cache-table approach is easier to maintain.

Step 5: Create Dashboard Tables

A simple dashboard cache structure might include two tables: one for metric cards and one for detail rows.

DashboardMetrics table:

• __pkMetricID
• MetricKey
• MetricLabel
• MetricGroup
• MetricValueNumber
• MetricValueText
• AlertLevel
• SortOrder
• RefreshTimestamp
• DrilldownScriptName
• DrilldownParamJSON

DashboardRows table:

• __pkDashboardRowID
• RowType
• SourceTable
• SourceRecordID
• DisplayTitle
• DisplayDetail
• DepartmentID
• DueDate
• Priority
• AlertLevel
• SortOrder
• RefreshTimestamp

If multiple users will refresh dashboards at the same time, consider adding a snapshot table.

DashboardSnapshots table:

• __pkSnapshotID
• AccountName
• DepartmentFilter
• DateStart
• DateEnd
• CreatedAt

Then relate each DashboardMetric and DashboardRow to a specific snapshot.

That prevents one user’s dashboard refresh from clearing or changing another user’s dashboard results.

Step 6: Write a Refresh Script

Create a script called something like:

Dashboard | Refresh Operations

The script should:

1. Capture the user’s filters
2. Create or update a dashboard snapshot
3. Clear old dashboard rows for that snapshot
4. Calculate each metric
5. Create metric records
6. Create detail row records
7. Commit the dashboard records
8. Navigate the user back to the dashboard layout

For example, the script might calculate:

• Count of late jobs
• Count of orders at risk
• Count of open quality issues
• Count of material shortages
• Total completed quantity this week

There are several ways to calculate these values.

You can use:

• Finds and found counts
• Summary fields
• ExecuteSQL
• Relationships
• Utility scripts
• Stored reporting tables

The best method depends on the file, data volume, and performance needs.

For a small dashboard, FileMaker finds and summary fields may be enough. For a more complex dashboard, a scripted cache can be easier to control.

Step 7: Build the Dashboard Layout

Create a dedicated dashboard layout.

A useful layout might include:

• Filter controls at the top
• Metric cards across the top
• A list of records needing attention
• One or two charts
• Drilldown buttons
• Last refreshed timestamp

Example metric cards:

• Late Jobs: 12
• At-Risk Orders: 7
• Open Quality Issues: 4
• Material Shortages: 9
• Units Completed This Week: 1,240

Each card should be clickable when possible. If a user clicks “Late Jobs,” the system should show the relevant jobs, not just the number.

That is what turns a dashboard from a display into a working tool.

Step 8: Add Drilldowns

A dashboard should help users move from summary to action.

Each DashboardRow can store:

• The source table
• The source record ID
• The row type
• A drilldown parameter
• An alert level

Then create a script called:

Dashboard | Open Selected Row

That script can inspect the row type and source record ID, then take the user to the correct layout and record.

For example:

• Late Job row opens the job record
• Quality Issue row opens the issue record
• Material Shortage row opens the material or job material record
• At-Risk Order row opens the order record

This makes the dashboard immediately useful.

Step 9: Use Conditional Formatting Carefully

Conditional formatting can help users identify what matters quickly.

For example:

• Red for late or critical items
• Yellow for warning items
• Green for healthy items
• Gray for informational items

Use this sparingly. If everything is highlighted, nothing stands out.

The goal is to make the next action obvious.

Step 10: Handle Permissions

Dashboards should respect FileMaker security.

Before building the dashboard, decide who should see what.

For example:

• Executives may see all departments
• Department managers may see only their department
• Front-line users may see only assigned jobs
• Accounting may see invoicing-related statuses only

If the source data is restricted, the dashboard should not accidentally expose it through summary records.

This is especially important if using a dashboard cache table. The cache should not store sensitive details that the user would not otherwise be allowed to view.

Step 11: Decide How Often It Should Refresh

Not every dashboard needs to update every second.

For some teams, refreshing when the layout opens is enough. For others, a refresh button may be better. Some dashboards may need a scheduled server-side refresh every 15 minutes, hourly, or overnight.

Ask what the dashboard is used for.

If it supports real-time production decisions, it may need frequent refreshes. If it supports daily management review, refreshing once in the morning may be enough.

Avoid unnecessary refreshes that slow down the system.

Step 12: Start Small

The first dashboard should not try to answer every question.

Start with a focused version:

• Five metric cards
• One exception list
• One chart
• Three drilldowns
• One refresh script

Then watch how people use it.

Do they click into late jobs? Do they care about throughput by department? Are the alert thresholds right? Are there metrics nobody uses?

A dashboard should evolve based on decisions, not decoration.

Final Thoughts

A practical FileMaker dashboard does not have to be complicated.

Start with the business questions. Map those questions to existing data. Add simple calculations where needed. Decide whether live reporting or a dashboard cache makes more sense. Build a focused layout with metric cards, exception lists, charts, and drilldowns.

The best dashboards help people act.

For many FileMaker systems, the data is already there. The opportunity is to make that data easier to see, understand, and use.

A modern way to manage vendor communication

For many businesses, vendor communication still happens through email chains, spreadsheets, attachments, and phone calls.

That can work when volume is low. But as soon as vendor updates become frequent, time-sensitive, or tied to compliance requirements, that process starts to break down. Someone has to chase missing information. Someone has to re-enter details into FileMaker. Someone has to confirm whether the latest document, shipment update, or delivery note is actually the current version.

Modern FileMaker systems do not need to work that way.

With Claris Studio, you can create a browser-based intake form or lightweight vendor portal that lets outside vendors submit information without giving them direct access to your FileMaker system.

What this could look like

A vendor receives a link to submit an update.

They open a mobile-friendly form, enter the requested information, upload supporting documents, and submit. That data can then flow into your FileMaker workflow, where your internal team reviews, approves, routes, or follows up.

This could be used for:

• delivery updates
• certificate of insurance submissions
• compliance documents
• vendor onboarding forms
• material specifications
• purchase order confirmations
• quality documentation
• change requests

The vendor gets a simple web experience. Your team gets structured data instead of another email thread.

Why this matters

The key benefit is not just convenience. It is control.

When vendor communication happens through inboxes and spreadsheets, the process becomes hard to track. Important details are scattered. Attachments get buried. Internal teams lose time copying data from one place to another.

A Studio-based intake process gives you a cleaner path:

Vendor submits update

   ↓

Studio captures structured data

   ↓

FileMaker stores and manages the workflow

   ↓

Internal team reviews, approves, or follows up

This keeps FileMaker as the operational source of truth, while giving outside users a much easier way to contribute information.

Where FileMaker still does the heavy lifting

The web form is only the front door.

FileMaker can still manage the core process behind the scenes, including:

• vendor records
• document status
• approval routing
• missing information flags
• audit history
• internal notes
• notifications
• reporting

That is the modern pattern: use Studio for external access, use FileMaker for operational control.

A practical example

Imagine a manufacturer that needs updated material certificates from vendors.

The old process might look like this:

A vendor emails a PDF. Someone downloads it. Someone renames it. Someone attaches it to a FileMaker record. Someone manually updates the status. Someone else follows up when the document is missing or expired.

The modern version could be much cleaner:

The vendor submits the certificate through a Studio form. FileMaker links it to the vendor record, marks it as pending review, alerts the right person, and stores the history for future reference.

No full FileMaker access required. No inbox archaeology. No spreadsheet tracker.

Can your FileMaker do this?

If your FileMaker system already tracks vendors, documents, inventory, purchasing, or compliance, this is a natural step in modernization.

The goal is not to replace your system. The goal is to extend it to the people who need to interact with it, without forcing them into your internal app.

Your vendors do not need to use FileMaker for your FileMaker system to work better.

FileMaker does not have to stay at the desk

Many people still think of FileMaker as something used in the office: desktop layouts, internal records, back-office workflows, and reports.

But modern FileMaker systems can support work wherever it happens.

For field teams, warehouse staff, inspectors, technicians, and mobile employees, that can make a major difference. Instead of writing notes on paper, texting photos, or waiting until the end of the day to update the system, they can capture information directly from the field.

What this could look like

A technician arrives at a job site.

They scan a QR code on a piece of equipment. The correct FileMaker record opens. They complete an inspection checklist, take photos, add notes, capture a signature, and submit the update.

Back at the office, the team can see the update immediately. No paper form. No photo hunt. No duplicate entry.

Where this is useful

Mobile capture can support a wide range of workflows:

• Equipment inspections
• Delivery confirmations
• Job site reports
• Installation checklists
• Maintenance logs
• Warehouse receiving
• Inventory counts
• Quality control reviews
• Field service updates
• Signed approvals

For organizations that already use FileMaker internally, this can be one of the most practical ways to modernize the system.

Why QR codes matter

QR codes create a simple bridge between the physical world and your FileMaker records.

Instead of asking a user to search for the right asset, project, delivery, or work order, the code can take them directly to the correct context.

That can reduce errors, save time, and make mobile workflows much easier for occasional users.

A basic flow might look like this:

Scan QR code

   ↓

Open the correct record

   ↓

Capture notes, photos, checklist items, or signature

   ↓

Submit update

   ↓

Notify office or update workflow status

This is especially useful when speed and accuracy matter.

Photos and signatures add context

Many field workflows depend on proof.

Was the item delivered?
Was the package damaged?
Was the equipment inspected?
Did the customer sign off?
Was the issue visible on site?

FileMaker can help collect that evidence in the same place as the operational record.

Photos, signatures, timestamps, user information, and structured fields can all work together to create a clearer record of what happened.

The business impact

The value is not just that the system becomes mobile. The value is that the process becomes cleaner.

Mobile capture can help teams:

• Reduce duplicate entry
• Prevent lost paperwork
• Improve accountability
• Speed up office follow-up
• Create better audit trails
• Give managers faster visibility
• Reduce delays between field work and office action

For many businesses, this is the difference between finding out what happened today and finding out what happened three days later.

Can your FileMaker do this?

If your team still relies on paper forms, texted photos, delayed updates, or manual re-entry after field work, FileMaker may be able to do more than you are asking of it.

A modern FileMaker system can connect the field to the office, the physical asset to the digital record, and the work being done to the people who need to act on it.

FileMaker does not have to live only at a desk.

FileMaker systems often hold more context than people have time to read

A mature FileMaker system usually contains years of useful history.

Customer notes. Service logs. Project updates. Support tickets. Inspection details. Meeting notes. Internal comments. Status changes.

The problem is not that the information is missing. The problem is that it can take too long to read through it all.

That is where AI-assisted workflows can be genuinely useful.

Instead of treating AI as a replacement for your process, you can use it as a way to make existing FileMaker data easier to understand.

What this could look like

A user opens a customer, project, or service record.

Instead of reading through dozens of notes, they click a button to generate a short summary:

• recent activity
• open issues
• important risks
• next steps
• unresolved questions
• key decisions

The summary appears inside FileMaker as a draft. A user can review, edit, and approve it before it becomes part of the official record.

That last part matters. AI should assist the workflow, not silently control it.

Why this matters

This is one of the most practical AI use cases because it solves a real business problem: the overload of unstructured information.

For example:

• A service manager needs the latest customer context before a call
• A project manager needs a quick summary of recent updates
• An operations lead wants to understand recurring issues across tickets
• A sales team wants a clean account brief before outreach
• An admin team wants to summarize intake notes before routing a request

FileMaker already stores the data. AI can help make that data faster to interpret.

A safer workflow pattern

The best version of this is not “AI writes over your records.”

A safer pattern looks like this:

FileMaker notes or logs

   ↓

AI generates a draft summary

   ↓

User reviews the result

   ↓

Approved summary is saved

   ↓

Original notes remain intact

This keeps the original record preserved while giving users a cleaner, faster way to understand what happened.

Where this fits best

AI summaries can be especially useful for:

• customer history
• service records
• project updates
• inspection notes
• support tickets
• internal activity logs
• meeting notes
• long-form intake responses

The best candidates are areas where the data is useful, but too time-consuming to review manually every time.

What to avoid

This should not be used carelessly.

AI-generated summaries should not automatically replace official notes, approve requests, make compliance decisions, or update important business fields without review.

The better model is simple:

AI drafts.
People approve.
FileMaker records the decision.

That gives you the benefit of faster understanding without giving up control.

Can your FileMaker do this?

If your FileMaker system has years of notes, logs, or customer history, AI-assisted summarization can make that history more usable.

This is not about adding a novelty chatbot to your database.

It is about helping your team access the important context faster while keeping FileMaker as the system that stores, structures, and governs the work.

Importing data into FileMaker should be easier than it often is.

For many FileMaker systems, imports fall into one of two categories. The first option is a pre-mapped import script, which works well when the incoming file always follows the exact same structure. The second option is FileMaker’s built-in import interface, which offers greater flexibility but often exposes too much of the database structure.

Neither option is ideal for everyday users.

Pre-mapped imports are simple but rigid. If a spreadsheet changes slightly, the import can break or require developer intervention. The built-in import interface is flexible, but it often requires users to understand field names, table structure, naming conventions, and the database backend.

The Custom Import Tool Add-On is designed to give FileMaker users a better middle ground.

It allows users to import data using friendly, easy-to-understand column labels instead of exact back-end field names. Users can create, save, modify, and reuse import templates, making recurring imports easier while still allowing flexibility when the incoming file changes.

What Is the Custom Import Tool Add-On?

The Custom Import Tool Add-On is a FileMaker add-on designed to make importing data more user-friendly, flexible, and controlled.

Instead of asking users to map spreadsheet columns directly to FileMaker field names, the tool lets a full-access user define friendly header options in advance. Once those mappings are configured, end users can build import orders using labels that make sense to them.

For example, instead of seeing a back-end field name like Customer::cust_primary_email, a user could simply choose “Customer Email.”

That small change can make imports much easier for non-technical users.

The tool also supports saved import templates. If a vendor, customer, department, or third-party system sends files in a consistent format, users can save that import structure and reuse it later. If the file changes, they can modify the template or make a one-time adjustment during the import.

Out of the box, the tool supports up to 20 columns, with the option to add more columns if needed.

Why FileMaker Imports Can Be Difficult

Imports are one of those tasks that seem simple until real-world data gets involved.

Spreadsheet columns may be renamed. Column order may change. Extra fields may be added. Some rows may need to be skipped. Some columns may not be needed at all. A file may contain multiple pieces of data in one column that need to be split into separate FileMaker fields.

For technical users, those issues are manageable. For everyday users, they can be frustrating quickly.

A user should not need to understand every field name in the database just to import a spreadsheet. They should not have to worry about accidentally mapping data to the wrong field. They should not have to call a developer every time a file has one extra column.

The Custom Import Tool Add-On is designed to reduce that friction.

It gives users a cleaner interface to choose what gets imported, what gets skipped, and how incoming data should be handled before it reaches the final destination table.

How It Works

The Custom Import Tool uses a staging-table approach.

Instead of importing data directly into the final destination table, the tool first imports the incoming file into a staging table. This gives users a chance to preview and review the data before completing the import.

That staging table is intentionally open and editable. Users can make corrections, clean up values, remove unwanted rows, or adjust the imported data before submitting it to the main system.

The basic workflow looks like this:

1. A full-access user maps friendly header labels to real FileMaker fields.
2. The data is imported into a staging table.
3. An end user selects or creates an import template.
4. The user selects which columns to import from the incoming file.
5. The user can preview, edit, skip, or adjust data as needed.
6. The final import script moves the staged data into the appropriate FileMaker table.

This gives users more control without exposing them to unnecessary back-end complexity.

Flexible Import Templates

One of the most useful features of the tool is the ability to create and modify templates.

If a company regularly imports files from the same source, such as a vendor spreadsheet, customer data export, inventory file, or order report, users can create a template once and reuse it.

Templates can also be adjusted on the fly.

If a file arrives with a slightly different column order, users can adjust the import order. If a column should be ignored, they can mark it to skip. If the change is temporary, they can make a one-time adjustment without permanently changing the saved template.

This makes the tool useful for both recurring imports and unpredictable one-off imports.

Preview Before You Commit

A major benefit of the staging-table approach is that users can see what they are about to import before the data reaches the final table.

That matters because import mistakes can be messy.

If data is imported directly into production records, a bad mapping or messy spreadsheet can create duplicate records, overwrite important values, or place information in the wrong fields. By staging the data first, users have a safer place to review what is happening.

Skipped rows and skipped columns are highlighted, making it easier to see what will and will not be included in the final import. Users can also edit the staged data before completing the process.

That creates a more forgiving import experience.

Create and Update Records in One Import

The Custom Import Tool can also support matching fields, allowing imports to create new records and update existing ones in a single process.

For example, a company may import a customer list in which some customers already exist in FileMaker, and others are new. With match fields configured, the import process can identify existing records and update them, and create new records where no match is found.

This can be especially useful for customer lists, inventory files, product catalogs, order updates, membership records, and other recurring data sources.

Ideas for How to Use It

The Custom Import Tool Add-On can be used anywhere FileMaker users need a more flexible import process.

Common use cases include:

• Importing customer or prospect lists
• Updating product catalogs
• Importing inventory counts
• Processing vendor price sheets
• Loading order data from external systems
• Importing membership or registration lists
• Updating contact information
• Cleaning and reviewing data before final import
• Creating controlled imports for non-technical users
• Handling recurring spreadsheet formats from customers, vendors, or departments

It can also be customized further with scripting.

For example, a developer could parse data from one incoming column into multiple FileMaker fields. A single “Full Name” column could be split into first and last name fields. A combined address field could be parsed into street, city, state, and ZIP code. A product description could be analyzed and separated into category, size, or model fields.

The add-on provides the import framework, but FileMaker developers can extend it to fit the needs of the specific system.

The Bottom Line

The Custom Import Tool Add-On is designed to make FileMaker imports easier, safer, and more flexible.

It provides users with a user-friendly interface for selecting import columns, saving templates, skipping rows or columns, previewing data, and making adjustments before the final import. At the same time, it gives developers a controlled structure for mapping fields, defining match logic, and customizing the import process.

For businesses that rely on recurring spreadsheet imports, this can save time, reduce errors, and make FileMaker easier for everyday users to work with.

Importing data will always require some structure. The goal of this tool is to make that structure easier for non-technical users to manage, reuse, and understand.

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.