Get the Type-Ahead Value List add-on

Tell us where to send it and we will email your download link right away.

Close

Yes. FileMaker scheduled reports can run entirely on FileMaker Server: a server schedule finds the right records, saves them as a PDF or Excel file, and emails that file to the people who need it, with no one pressing a button. The details that make it reliable are server compatibility, file paths, and logging.

Picture an operations manager on a Monday morning. Before the sales meeting, she opens FileMaker, finds the open orders, saves a PDF, and types six addresses from memory. If she is out sick, the meeting runs on last week’s numbers.

The report exists; the routine around it is the problem

Most FileMaker systems already have the layout. What does not scale is the human routine wrapped around it.

Someone has to remember the day, run the right find, and know who gets the file this month.

A scheduled report removes all three. A basic flow might look like this:

FileMaker Server schedule fires at 6:00 AM

↓

Server-side script finds and sorts the records

↓

Script saves the found set as a PDF or Excel file

↓

Script looks up who should receive it

↓

Send Mail delivers the file through SMTP

↓

Script writes a log record: sent, failed, or skipped

If you already build reports in FileMaker, as in our walkthrough on building year-end profit and loss reports directly in FileMaker, this is the delivery layer.

How does FileMaker Server run a report on a schedule?

In Admin Console (the browser-based FileMaker Server administration tool), you create a schedule of type FileMaker Script. Claris documents that you choose the hosted database, the script, the FileMaker account the script runs under, and when it runs. Repeat options are Once, Daily, Weekly, and Every N Days, with an optional end date.

If a run is still going when the next one is due, FileMaker Server skips the second run, and you can set a timeout so a hung script ends on its own.

There is no monthly option. For a month-end report, schedule the script daily and have it exit unless today is the last day of the month. A test such as Day ( Get ( CurrentDate ) + 1 ) = 1 handles that.

Which script steps work on the server, and which do not?

This is where first attempts break. A script that works from a button in FileMaker Pro can skip steps on the server. Claris lists compatibility on each step’s help page:

• Save Records as PDF: partially supported. With dialog: On, Automatically open file, and Create email with file as attachment are not supported on the server. In current versions, the step can save to a file path, a container field, or a variable.
• Save Records as Excel: not supported on FileMaker Server. Use Export Records with the Excel Workbooks (.xlsx) file type instead. Claris notes that server-side Export Records cannot write .fmp12 files and can only write to permitted folders.
• Send Mail: partially supported. Server-side scripts can send via SMTP or OAuth 2.0, but not through an email client such as Outlook on someone’s desktop.

Claris also advises that the layout’s fonts be installed on the server, or the PDF will not render them correctly.

File paths: the Documents folder and the temporary folder

Server-side scripts can only read and write in the FileMaker Server Documents folder or the temporary folder, plus their subfolders. Paths containing “..” are invalid.

• Get ( TemporaryPath ) returns a folder for that script’s session, deleted when the script finishes. Use it for a file you create and send in the same run.
• Get ( DocumentsPath ) returns the server’s shared Documents folder. Use it when a later script or another process needs the file.

A short sketch of the core steps (illustrative; exact options vary by version):

Set Error Capture [ On ]

Go to Layout [ “Open Orders Report” ]

Perform Find [ Restore ]

Sort Records [ Restore ; With dialog: Off ]

Set Variable [ $path ; Value: “file:” & Get ( TemporaryPath ) & “Open Orders.pdf” ]

Save Records as PDF [ Save to: File ; $path ; With dialog: Off ; Records being browsed ]

Send Mail [ Send via SMTP Server ; To: $recipients ; Subject: … ; Attach: $path ]

Set Variable [ $error ; Value: Get ( LastError ) ]

Pull recipients from data, not from the script

Hard-coded addresses break quietly. People change roles, contacts leave, and nobody remembers the script exists.

Instead, keep a Report Subscriptions table: report name, contact, email, active flag, and an optional filter (a rep who only wants their territory). The script finds the active subscribers and builds the To list from them. Claris documents that Send Mail accepts addresses separated by semicolons or returns, and can collect addresses across a found set.

Now the sales manager adds a new rep to the Monday report from a layout. No script edit.

Log every run, including the failures

A scheduled job that fails silently is worse than a manual one, because everyone assumes it ran. Give each run a record in a Report Log table:

• What and when: report name, run time, record count, file name.
• Who: the recipient list as sent.
• Outcome: Get ( LastError ) after the save and the send, with a status of sent, failed, or skipped (zero open orders, for example).
• The file, optionally, in a container field so someone can resend it.

Then have the script email an admin whenever a run logs failed or skipped, so nobody has to remember to check. FileMaker Server also records schedule results and skipped steps in its Event.log.

Where FileMaker scheduled reports usually fail

• Privileges. The schedule runs under the account you pick in Admin Console. Save Records as PDF needs the Allow printing privilege and exporting generally needs Allow exporting, unless the script runs with full access.
• Container and file paths. Files outside the Documents or temporary folders are not written, and temporary files vanish when the script ends.
• SMTP certificates. If the mail server’s SSL certificate cannot be verified server-side, Claris notes that Send Mail behaves as if canceled. Test against your real mail server.
• One-per-record sends. If one email fails in a one-per-record SMTP send, the rest are not sent. Loop and log each send instead.
• Time zones. A scheduled script reads the server’s clock. A hosted server set to UTC can make “yesterday’s shipments” the wrong yesterday, so calculate date ranges explicitly.

If your mail server is the weak link, our guide on sending emails from FileMaker using SendGrid covers an API-based alternative to SMTP, including attachments. Our post on sending calendar invites through FileMaker Pro shows another file FileMaker can generate and send.

Three reports worth scheduling first

• Weekly open orders (PDF). Monday at 6:00 AM to sales and customer service, with promised ship dates.
• Daily shipping summary (Excel). End of day to the warehouse lead and accounting as .xlsx, ready to reconcile.
• Month-end inventory value (PDF and Excel). Runs daily, exits unless it is month-end, then sends a PDF summary to the owner and .xlsx detail to the accountant.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We help teams turn the reports they already run by hand into scheduled, logged deliveries on FileMaker Server.

Frequently asked questions

Can FileMaker Server email a report without anyone logged in?

Yes. A FileMaker Script schedule in Admin Console runs the script on the server under a FileMaker account you specify, and Send Mail can deliver through SMTP or OAuth 2.0 with no user session open.

Why does my Save Records as Excel step not work on the server?

Claris lists Save Records as Excel as not supported on FileMaker Server. Use Export Records with the .xlsx file type in server-side scripts instead.

Do I need a plug-in to schedule FileMaker reports?

Usually not. FileMaker Server schedules, the PDF and export script steps, and SMTP Send Mail are built in. A mail service such as SendGrid is optional if your own mail server gives you trouble.

Can your FileMaker email the Monday report before anyone is in the building? Bring the report your team rebuilds every week to a free 20-minute Data Health Check and we will show you what it takes to put it on a schedule.

P.S. Already know which reports you want automated? The 5-Hour Developer Assist Package gives you five hours with a Kyo developer to use any time within a year.

A useful FileMaker audit trail answers five questions about every change: who made it, what record and field it touched, when it happened, the old value, and the new value. FileMaker 2025 and FileMaker 2026 provide building blocks but not a finished, field-level audit log, so you build or install one, lock it down, and review it on a schedule.

Picture a quality manager three days before a customer audit. The auditor wants to know why the tolerance on a part specification changed in March. The record shows the current value and a “last modified by” name. It does not show the old value or the two edits before the last one. That gap is what an audit trail closes.

Quick takeaways

• Check whether your system captures all five facts: who, what, when, old value, new value.
• List integrations that write through the Data API or OData and confirm those changes get logged.
• Open your log table’s record access privileges and make sure everyday users cannot edit or delete entries.
• Agree on a retention period with whoever owns compliance, and put it in writing.
• Put a 30-minute monthly log review on someone’s calendar.

What does an auditor actually ask for?

Whether the audit comes from a customer, your quality system, or a regulator, the questions reduce to the same facts:

• Who. The account that made the change, not a shared login or a guess.
• What. The table, the record, and the specific field that changed.
• When. A timestamp you can trust, ideally from the server clock rather than a laptop.
• Old value. What the field said before the edit.
• New value. What it says now.

Capture those five facts for creates, edits, and deletes. A deleted line item that leaves no trace is the hardest change to explain, because nobody can see that it is missing.

FileMaker gives you the parts, not the finished log

No single native FileMaker feature produces a field-level history with old and new values. Our earlier overview of audit logging and activity monitoring in FileMaker 2025 covers the compliance case; here is what the platform provides.

The OnWindowTransaction script trigger. Added in version 20.1 and available in FileMaker 2025 and 2026, this file-level trigger runs a script after records are committed. Claris documents that it passes a JSON parameter with the file, base table, record ID, and operation (“New”, “Modified”, or “Deleted”) for each record, plus an optional context field, and suggests it for “an audit log of changes, who makes them, and when.”

{

“FileName” : {

“BaseTableName” : [

[ “Operation”, RecordID, FieldContent ],

…

]

}

}

Two documented limits matter. Reverted records do not fire it, which is correct. Direct access through the FileMaker Data API or OData API (the web interfaces other software uses to read and write your data) does not fire it either, although scripts run through those APIs can, so an integration writing straight to your tables goes unseen. The trigger also reports only that a record changed, without the old field values, so capturing them takes additional design.

Get functions. Get(AccountName) returns the authenticated account of the current user. Pair it with a server-side timestamp such as Get(CurrentHostTimestamp) so every entry uses one clock.

Auto-enter modification fields. A field can auto-enter the modification timestamp and account name. Each edit overwrites it, so it only tells you who touched the record last.

FileMaker Server logs. Claris documents that the Access.log records clients connecting and disconnecting, which databases they opened, and which account they used. It answers “who was in the system at 11 p.m.” but not field changes, and when it reaches the size limit it becomes Access-old.log and a new file starts. It is not a long-term archive.

The FileMaker 2025 and 2026 release notes we reviewed (2026 centered on Standby Server, Remote Backup, PDF script steps, and AI context) do not add a built-in, field-level audit log.

Build it yourself, or install one that already works

A homegrown log usually starts as a history table and an OnWindowTransaction script. The hard part shows up later. Someone adds a field and forgets to log it, or adds a table and nobody wires it in, and a change to a related record can leave the parent looking untouched. The gap surfaces when an auditor asks for history you never captured.

Kyo built the free Audit Log & Version History add-on for exactly that problem. Bringing a table under logging takes two script triggers. The add-on then captures every non-container field that changed, plus who changed it and when, even if the field was not on the layout. Two optional features extend it:

• Related Record Logging records changes to related records, including creation and deletion, so a deleted line item leaves evidence.
• Record Versioning & Restoration stores the previous version of a record on each change and lets an authorized user restore it.

A user edits an order line

↓

Every changed non-container field is captured with old and new value

↓

The log records the account and the time

↓

An authorized reviewer filters the history by record, field, or user

If your audit scope includes documents or images in container fields, plan for those separately.

Who can see the log, and who can change it?

An audit log that anyone can edit is a note, not evidence. Privilege sets make it trustworthy.

Record access privileges can be set per table, with separate View, Edit, Create, and Delete settings. A reasonable starting point for the log table:

• Everyday users: no access to view, edit, create, or delete log records.
• Reviewers (quality, operations, an auditor’s account): view only.
• The logging script: set to run with full access privileges, so it can write entries the user cannot. Only Full Access accounts can grant this.

Use record access privileges, not just layout privileges. Claris notes that layout privileges protect only a single view of the data.

Then keep the Full Access list short, because those accounts can still change anything, log included. A shared “admin” login undoes the “who” in every entry.

Your FileMaker audit trail needs a written retention policy

There is no single correct number. Retention depends on customer contracts, your quality system, and regulations that apply to your industry and data, and can differ by record type. To set it:

1. List every requirement that applies: customer agreements, quality manual, regulations, legal holds.
2. Take the longest period for each record type and confirm it with whoever owns compliance.
3. Write the policy down, including who approved it.
4. Archive older entries to a read-only file instead of deleting them, and include it in backups.
5. Export any server logs you need before they roll over.

For a broader pre-audit checklist, see FileMaker for year-end compliance and audit readiness.

A monthly review routine catches problems before an audit does

The log only helps if someone looks at it. A 30-minute monthly review is a reasonable starting point:

1. Confirm logging still works. Make a test edit on a logged table and find it in the log.
2. Check coverage. Compare tables and fields added this month against what is logged. Our post on using the Admin API to audit your database shows one way to pull schema details.
3. Review deletions. Every deleted record in a sensitive table should have an obvious reason.
4. Scan high-risk fields. Prices, quantities, specifications, and approvals changed by unexpected accounts or after hours.
5. Check access. Skim the Access.log for unfamiliar accounts and confirm the Full Access list has not grown.
6. Record the review. Note the date, reviewer, and follow-ups. Auditors often ask whether logs are reviewed as well as whether they exist.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. Our audit work starts with one question: which changes could you not explain today?

Frequently asked questions

Does FileMaker have a built-in audit trail?

Not as a finished feature. FileMaker provides building blocks such as the OnWindowTransaction script trigger and FileMaker Server access logs, but a field-level history with old and new values requires a custom build or an add-on.

Can an audit log track changes made through the FileMaker Data API?

It depends on how the change arrives. Claris documents that direct Data API or OData access does not activate OnWindowTransaction, while scripts run through those APIs can. Route integration writes through scripts if they need to be logged.

Can users delete their own entries from the audit log?

Not everyday users, if privilege sets are set up as described above. Accounts with Full Access can still change the log, which is why that list should stay short. Give everyday users no access to the log table, give reviewers view-only access, and let the logging script run with full access privileges so everyday users cannot write or change entries.

If you want the log without building it, download the free Audit Log & Version History add-on, or talk with Kyo Logic about which tables to log first.

Airtable is often the fastest choice for a lightweight team database. Smartsheet is usually the easiest fit for spreadsheet-shaped project and work tracking. FileMaker is the stronger choice when the business needs a custom relational system, controlled workflows, mobile or offline use, and room to grow beyond a template.

The right platform depends on what the data must do after the pilot succeeds.

This article is an update to [Kyo Logic’s existing real-world comparison](https://kyologic.com/2026/01/airtable-vs-smartsheet-vs-claris-filemaker-real-world-pilots-outcomes-part-3/). It should strengthen the current page rather than create a competing URL.

## The short verdict

Choose Airtable when a small team needs to organize related lists quickly, the workflow is lightweight, and a template or simple automation gets the team most of the way there.

Choose Smartsheet when the team thinks in rows, columns, schedules, and project plans, and adoption depends on a familiar spreadsheet model.

Choose FileMaker when the business has complex relationships between customers, jobs, assets, documents, and transactions; users need role-specific screens; or the pilot is expected to become an operating system rather than remain a tracker.

## What problem are you actually solving?

A three-person marketing team and a 75-person manufacturing company can both say, “We need one place for our data.” They do not mean the same thing.

The marketing team may need campaigns, assets, owners, dates, and approvals. Airtable or Smartsheet can make that work visible quickly.

The manufacturer may need customers, quotes, parts, jobs, routings, inspections, shipments, invoices, and permissions. Those records are connected. A change to one can affect several others. That is application behavior, not just data organization.

Start by naming the decision the system must support. Then identify who acts on it, what rules apply, and what happens when the data is incomplete.

## How does Airtable fit?

Airtable makes it easy to create a shared base with tables, linked records, views, forms, and automations. It is approachable for teams that want more structure than a spreadsheet without commissioning a custom application.

A coordinator can build a content calendar, vendor tracker, request queue, or lightweight CRM. Different views can show the same records as a grid, calendar, kanban board, or form-driven intake process.

That speed is Airtable’s advantage. It is also the reason teams should define an exit test before the pilot. A base that begins as a tracker can accumulate formulas, automations, duplicated fields, and exceptions. The question is whether the resulting system remains understandable and controlled.

## How does Smartsheet fit?

Smartsheet starts from a model many business users understand. The grid feels familiar, and the platform adds project planning, dependencies, forms, dashboards, approvals, and reminders.

A project manager can track tasks, dates, owners, budgets, and status without asking the team to learn a new application structure. That makes Smartsheet useful for implementation plans, portfolio reporting, operational checklists, and approvals.

The tradeoff appears when the data becomes more relational than project-shaped. A customer can have many locations. A location can have many assets. An asset can have many service events. Each event can have parts, technicians, photos, and approvals.

A grid can display those records, but the experience may become a collection of sheets, cross-sheet references, and workarounds. Smartsheet remains useful for planning. It may not be the best long-term home for a custom transactional system.

## Why does FileMaker fit complex operations?

FileMaker is designed for custom applications around related data and business rules. The interface can be built for the person doing the work rather than exposing the database as a general-purpose grid.

A field technician opens a mobile screen

v

The correct customer and asset are selected

v

Required inspection fields guide the visit

v

Photos and signatures attach to the service record

v

The completed record returns to the office workflow

No row hunt. No cross-sheet lookup. No second entry.

The same system can present a different interface to dispatch, accounting, management, or the customer. Each role sees the fields and actions it needs. Scripts can enforce steps, integrations can exchange approved data, and permissions can limit access.

The goal is not to prove that FileMaker can imitate Airtable or Smartsheet. The goal is to decide when the business has moved from a tracker to a custom application.

## What should a pilot prove?

Feature lists make every platform look capable. A pilot reveals the cost of building, the speed of adoption, and what happens when the workflow meets exceptions.

Test one complete workflow, real records with realistic volume, the permissions different roles need, the hardest relationship in the data, one integration or export, and the report management asks for every week.

The pilot should define a stopping rule. If the team spends more time maintaining workarounds than using the system, the platform may no longer fit the job.

## When should you move to FileMaker?

Evaluate the move when users enter the same information in more than one place, important rules live in training documents, roles need different screens, reporting requires manual cleanup, integrations carry more of the process, and exceptions are becoming normal.

FileMaker can encode that process directly. It can still integrate with Airtable or Smartsheet where those products remain useful. Modernization does not require a rip-and-replace project.

## How should you make the decision?

Score the next two years, not the first two weeks.

1. Data relationships: How many connected record types exist?

2. Workflow rules: Must the system validate, route, calculate, approve, notify, and log actions?

3. User experience: Can everyone use a shared grid, or do roles need guided screens?

4. Mobility: Do users need mobile access, device features, or work with limited connectivity?

5. Scale and limits: Review current vendor documentation for record, attachment, automation, API, and user limits.

6. Ownership: Who will administer, test, document, and approve changes?

Use Airtable when the process is still taking shape. Use Smartsheet when the spreadsheet model fits the job. Use FileMaker when the business needs related data, role-specific workflows, and deeper control.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England businesses. Our recommendation is to pilot the hardest workflow, not the easiest screen.

## Related reading

– [Can Your FileMaker Do This: FileMaker vs AI Built Apps vs Enterprise Suites Guide](https://kyologic.com/2025/10/can-your-filemaker-do-this-filemaker-vs-ai-built-apps-vs-enterprise-suites-guide/)

– [Why FileMaker is an Inexpensive Alternative to ERPs](https://kyologic.com/2023/12/how-filemaker-can-reshape-compliance-management/)

## FAQ

**Is Airtable easier to set up than FileMaker?**

Airtable is usually faster for a lightweight shared database. FileMaker requires more design work but supports a tailored application, deeper rules, and role-specific interfaces.

**Is Smartsheet a database?**

Smartsheet can organize business information, but its primary model is spreadsheet-shaped work management. A relational application may fit better when records and rules become complex.

**When should a business choose FileMaker?**

FileMaker is a strong fit when connected data, guided workflows, permissions, mobile work, integrations, and long-term customization matter more than immediate template setup.

**Can these platforms work together?**

Yes. A business can keep Smartsheet for planning or Airtable for a team workflow while FileMaker manages the operational system of record.

If your tracker is becoming a business-critical application, Kyo Logic can help determine whether to improve the current platform or move the core process into FileMaker.