Author: Kyo Logic

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.

AI can be useful inside a FileMaker system, but the safest approach is not to let an AI assistant freely change records, rewrite logic, or make business decisions on its own.

A better approach is to expose specific, approved FileMaker actions.

In this guide, we will walk through a simple example: allowing an AI assistant to help complete a job and notify accounting when the job is ready for invoicing.

The goal is not to replace FileMaker’s business logic. The goal is to make an existing FileMaker workflow easier to access.

What We Are Building

A user should be able to ask something like:

“Mark job 10482 complete and let accounting know it is ready for invoicing.”

Behind the scenes, the AI assistant should not invent the process. It should call a FileMaker script that already knows how to handle the workflow safely.

That script should:

• Find the correct job
• Confirm the job is eligible to be completed
• Check required fields
• Update the job status
• Create or flag the invoice draft
• Notify accounting
• Log the action
• Return a clear success or error message

The important design principle is simple: AI can request the action, but FileMaker performs the action.

Suggested Data Structure

For a basic version, you might already have a Jobs table. If not, this example assumes something like the following.

Jobs table:

• __pkJobID
• JobNumber
• CustomerID
• Status
• TargetShipDate
• CompletedAt
• CompletedBy
• ReadyForInvoicing
• AccountingNotifiedAt
• InvoiceDraftID
• MissingRequirements
• LastWorkflowError

You may also want an audit table.

AI_ActionLog table:

• __pkActionLogID
• CreatedAt
• Source
• RequestedBy
• RequestText
• ToolName
• TargetTable
• TargetRecordID
• ParametersJSON
• ResultJSON
• ErrorCode
• Status

This log table is important. If an AI assistant is going to request actions inside FileMaker, you should be able to review what was requested, what script was called, which record was affected, and what result was returned.

Step 1: Build the FileMaker Script First

Start inside FileMaker.

Create a script called something like:

AI | Complete Job and Notify Accounting

This script should not assume the request is valid. It should validate everything.

A simple script flow might look like this:

1. Set Error Capture On
2. Allow User Abort Off
3. Read the script parameter as JSON
4. Extract the job number or job ID
5. Find the job record
6. Confirm the job exists
7. Confirm the job is not already completed or cancelled
8. Check required fields
9. If required data is missing, return a JSON error
10. Update the job status
11. Set completion fields
12. Create or flag the invoice draft
13. Notify accounting
14. Write to the audit log
15. Commit the record
16. Exit the script with a JSON result

A script parameter might look like this:

{

  “jobNumber”: “10482”,

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

  “requestText”: “Mark job 10482 complete and let accounting know it is ready for invoicing.”

}

A successful script result might look like this:

{

  “success”: true,

  “jobNumber”: “10482”,

  “status”: “Ready for Invoicing”,

  “message”: “Job 10482 has been marked complete and accounting has been notified.”

}

An error result might look like this:

{

  “success”: false,

  “jobNumber”: “10482”,

  “error”: “Missing required fields”,

  “missingFields”: [“Completed Quantity”, “Final Inspection Date”],

  “message”: “Job 10482 cannot be completed until the missing fields are filled in.”

}

This result is what allows the AI assistant to respond clearly to the user.

Step 2: Make the Script Safe

This is the most important part of the implementation.

Do not expose a script to an AI assistant until the script can safely handle invalid, incomplete, or unexpected requests.

At minimum, the script should check:

• Does the job exist?
• Is the job already complete?
• Is the job in a status that can be completed?
• Are required fields filled out?
• Does the account running the script have permission?
• Should this action be logged?
• What happens if notification fails?
• What happens if the invoice draft cannot be created?

The script should also commit changes before returning a success result.

If something fails, return a controlled error message. Do not leave the AI assistant guessing.

Step 3: Use a Dedicated Layout Context

For workflows that may be run from outside the normal FileMaker interface, create dedicated layouts for automation or API-style access.

For example:

• API_Jobs
• API_Invoices
• API_ActionLog

These layouts should include only the fields needed for the workflow.

This helps keep the integration cleaner. It also reduces the chance that future layout changes made for human users will accidentally affect an automation workflow.

Step 4: Configure Privileges Carefully

Use a dedicated account or privilege set for the MCP connection.

That account should only have access to what the workflow requires. In many cases, that means limited access to the relevant tables and scripts, not full access to the entire file.

The script itself may need elevated privileges in specific cases, but that should be handled intentionally. The goal is to let users complete approved actions without giving the AI assistant broad access to the whole system.

A good rule of thumb:

Give the AI assistant access to tools, not the entire workshop.

Step 5: Expose Only the Approved Tools in Claris MCP

Once the FileMaker workflow is ready, configure the Claris MCP connection.

In Claris MCP, select only the tables and scripts required for this use case.

For this example, you might expose:

• A read or find tool for Jobs
• The script AI | Complete Job and Notify Accounting

You may not need to expose create, update, or delete tools for Jobs if the script handles the action. If those tools are generated, review whether they should be turned off.

This is where the implementation becomes safer. The AI assistant does not need permission to update any job field directly. It only needs permission to call a controlled FileMaker script that knows how to validate and complete the workflow.

Step 6: Improve the Tool Description

The tool name and description matter because they help the AI assistant understand when to use the tool.

Instead of leaving a generic script description, write something clear.

Example tool title:

Complete Job and Notify Accounting

Example tool description:

Use this tool only when a user asks to mark a job complete and send it to accounting for invoicing. Requires a job number. The FileMaker script will validate required fields, update the job status, notify accounting, and return a success or error message.

The input schema should also be clear.

Suggested input fields:

• jobNumber
• requestedBy
• requestText

The more specific the tool is, the more predictable the assistant’s behavior will be.

Step 7: Test With Realistic Prompts

Test the workflow with both normal and messy requests.

Examples:

• “Mark job 10482 complete.”
• “Complete job 10482 and notify accounting.”
• “Can you send job 10482 to invoicing?”
• “Finish the Smith job and tell accounting.”
• “Close out job 10482, unless it is missing anything.”

Then test failure cases:

• A job that does not exist
• A job that is already complete
• A job missing required fields
• A job in a status that cannot be completed
• A user who should not be allowed to request the action

The script should return clear results in every case.

Step 8: Keep FileMaker in Control

This pattern works best when the AI assistant is treated as an interface layer.

The AI can understand the request, collect the required input, and call the approved tool. But FileMaker should remain responsible for the actual business rules.

That includes:

• Validation
• Permissions
• Status changes
• Notifications
• Record creation
• Audit logging
• Error handling

This keeps the implementation practical and safer.

Final Thoughts

Claris MCP introduces a new way for AI assistants to interact with FileMaker systems, but the best use cases are controlled.

Start with one small workflow. Build the FileMaker script first. Make it safe. Return clear JSON results. Expose only the tools the assistant needs. Test failure cases carefully.

The goal is not to let AI take over your FileMaker solution. The goal is to make trusted FileMaker workflows easier for users to access.

For many businesses, that is the right balance: a conversational front end with FileMaker still providing the structure, security, and reliability behind the scenes.

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.