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.