Author: Kyo Logic

Job shop production scheduling outgrows a whiteboard when the board can no longer hold the four things a schedule depends on: capacity, routing, material, and due dates. The fix is getting those inputs into one place, visible on the floor, before you automate anything clever.

Here is a Monday we hear about often in job shops. The production manager arrives at 6:45, and the whiteboard says the CNC mill runs brackets first, then housings. Over the weekend, a customer called the owner and a rush job jumped to the top. Housing material has not arrived. Second shift scrawled a note that the bracket fixture is cracked. By 7:30, three people have rewritten the same column, and the saw sits idle because nobody knew it was free.

Nobody did anything wrong here. The board just had no room for all the information it was being asked to hold.

The whiteboard stops working before anyone admits it

Shops rarely decide to leave the whiteboard. They drift away one workaround at a time: a spreadsheet, then another for material, then a text thread for hot jobs. The signs:

• Constant reshuffles. The job order changes several times a day, by memory.
• Hot jobs that never cool down. When everything is urgent, nothing is clearly next.
• Idle machines next to a backlog. Work is waiting at the wrong machine or for the wrong part.
• Late news on due dates. Someone learns a job is late on the day it should ship.

Kyo has written before about why small production issues turn into big delays. The schedule is where every one of those delays eventually lands.

What does a real schedule need to know?

In most job shops, four inputs matter, and each usually lives somewhere different today.

• Capacity. Hours each work center (a machine, cell, or crew doing one kind of operation) actually has this week, after maintenance and absences. Often it lives in the production manager’s head.
• Routing. The sequence of operations a part follows (saw, mill, deburr, inspect), with setup and run time for each. It may sit on a traveler (the paper packet that follows a job through the shop), in an ERP (enterprise resource planning, the system that handles orders, inventory, and accounting), or nowhere at all.
• Material. Whether stock, purchased parts, and outside processing are on hand. Usually that is a purchasing spreadsheet or the buyer’s inbox.
• Due dates. The date promised to the customer, and whether it changed. That is in the order system, in email, or in the owner’s last phone call.

When these live in four places, people reconcile them by hand at the whiteboard. Kyo’s article on managing work order requirements and milestones covers keeping job details in one record, the foundation scheduling builds on.

Do you need finite capacity scheduling or a better priority board?

Finite capacity scheduling means the schedule only loads each machine with as much work as it can actually do in the time available. If the mill has 40 hours this week, the schedule will not give it 55. Infinite capacity planning, by contrast, lines jobs up by due date and assumes the hours will be there.

A priority board is simpler. It ranks jobs and shows what is next at each work center, without checking whether everything fits.

• A priority board is often enough when routings are short and the real problem is that nobody can see the current order.
• Finite capacity starts to earn its keep when jobs share bottleneck machines, setups are long, and you regularly promise dates that the floor cannot hit.

Starting with the board and adding capacity math later is a perfectly good path.

Put the schedule on the floor without another login

A schedule on the production manager’s laptop is just a private whiteboard. Operators need to see what is next at their station and report when a job starts, stops, or hits a problem. That usually means a shared screen or tablet at each work center showing its queue, with one-tap start, complete, and hold. Operators do not need a separate login, and nobody has to walk to the office to see what is next.

Those updates also give you what the whiteboard never could: actual times. Kyo’s post on how to gather real-time production statistics shows how that data turns schedule guesses into numbers you can trust.

Automate in stages: visibility, then capacity, then what-if

Stage 1: visibility. One job list, one queue per work center, live status from the floor.

↓

Stage 2: capacity. Routing times and available hours, so overloaded machines get flagged.

↓

Stage 3: what-if. Test a rush job or machine outage and see which due dates move.

Each stage pays off on its own. Stage 1 alone can take a lot of the Monday-morning rewriting off the production manager’s plate.

The platform matters less than the inputs. Some shops use a scheduling module in their ERP. Others build a custom application on a platform like Claris FileMaker, which can keep jobs, routings, and floor updates in one place across desktop, iPad, and web browser. The right answer matches how your floor works.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We help job shops pull capacity, routing, material, and due dates into one schedule the whole floor can see.

Frequently asked questions

Can a spreadsheet handle job shop production scheduling?

For a while, yes, if one person owns it and the job mix is stable. It struggles once several people update it at once and material and routing data live elsewhere.

What is the difference between an MES and a scheduling tool?

An MES (manufacturing execution system) tracks what is happening on the floor in real time: job status, labor, quality checks. A scheduling tool decides what should happen next. The two work best when they share the same job data.

Do we need accurate routing times before we start?

No. Start with the times you have and let actual floor data correct them over a few weeks.

Not sure your job data is solid enough to schedule from? Book a free 20-minute Data Health Check and we will tell you what we see.

Engineering change control is the process that decides how a drawing or spec change gets requested, approved, and released, so every open job runs to the current revision. When it works, the machinist never has to wonder which print is right. When it does not, the floor finds out the hard way.

Here is the kind of Tuesday we hear about from contract machining shops. The engineer updated a bracket drawing to Rev C last week, moving one hole 0.020” for a customer fit issue. The traveler (the paper packet that follows a job through the shop) still holds a Rev B print from when the job was released. The operator runs 200 parts to Rev B. Inspection catches it two days later, after the parts have already gone to the plater.

How does the wrong revision reach a machine?

Almost never through carelessness. It happens because the revision lives in one place and the work lives in another.

• The CAD folder has the new drawing, but nothing tells the scheduler that three released jobs use it.
• Printed travelers outlive the revision they were printed against.
• The customer’s change arrives by email to whoever answered the phone, and stays in that inbox.
• Approval is a hallway conversation, so nobody can say later who signed off or when.

The cost shows up as scrap, rework, rush material, and a hard customer conversation. On an audited part, add a nonconformance report.

Give every change request a record of its own

The fix starts with two plain definitions. An ECR (engineering change request) is the formal ask: someone says “this part should change, and here is why.” An ECO (engineering change order) is the approved, released change: the decision that the new revision is official and what happens to work in progress.

An ECR can come from anyone, including the customer or an operator who sees a tolerance that cannot be held. An ECO is released by the people who own the design and the schedule.

A lightweight flow can look like this:

Someone submits an ECR with the part, current revision, reason, and markup

↓

Engineering reviews and drafts the new revision

↓

Quality and production weigh in on impact (tooling, inspection, open jobs)

↓

Approver signs off and the ECO is released

↓

New revision becomes the only one available for new work, and affected jobs are flagged

Nothing here needs a large team. It needs one place where the request lives, a clear status (submitted, in review, approved, released), and a named approver.

Linking revisions to open jobs is where control actually happens

When each job records the part number and revision it was released against, releasing an ECO can produce a list: every open job, every unshipped order, and every kitted traveler still pointing at the old revision. Each one gets a decision. Let it finish on Rev B because the customer agreed. Stop it and reprint. Rework the parts already made.

That decision gets recorded on the job, so nobody has to remember it. Kyo’s article on customizing production steps and requirements shows how routing and requirements can be tied to the specific job, which is the same structure a revision link depends on.

One shop rule needs no software at all: pull obsolete prints the day they are replaced instead of filing them next to the new ones.

Where do customer-specific requirements belong?

On the order, attached to the revision they apply to. Contract manufacturers often run one part for two customers with different marking or inspection rules. If those rules live in a sales rep’s notes, a revision change can quietly drop them.

Kyo’s post on reviewing and adopting requirements for specific orders covers how to capture those terms at order entry so they travel with the job. When an ECO releases, the change record should show whether any customer-specific requirement is affected, and who confirmed it.

The audit trail comes from the records you already keep

If you are certified to a quality standard, or your customers audit you against one, expect questions about how drawing revisions are controlled and how you know the floor used the right one. The exact requirements depend on the standard and the customer, so confirm them with your quality lead or registrar.

A change process built as records can answer many of those questions directly. Each ECR and ECO carries who asked, who approved, when it released, and what was decided for each affected job. Kyo’s article on maintaining historical records for future reference and replication shows why that history pays off when a part is reordered years later.

This can be built in many tools. A PLM (product lifecycle management) system may fit if you have a large engineering team. Some manufacturers do better with a focused workflow connected to the job and order data they already run, and a custom Claris FileMaker app is one way to build that without replacing the systems that work.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We can help shops connect engineering changes to the jobs and orders they affect, so the floor builds to the released revision.

Frequently asked questions

What is the difference between an ECR and an ECO?

An ECR (engineering change request) proposes a change and explains why. An ECO (engineering change order) is the approved, released change that makes the new revision official and decides what happens to work already in progress.

Do we need PLM software for engineering change control?

Not necessarily. Many manufacturers only need change requests, approvals, and released revisions linked to their jobs and orders, which a focused custom workflow can handle.

What should happen to jobs already running when a revision changes?

Each affected job needs a recorded decision: finish to the old revision with customer agreement, stop and reprint, or rework.

If revisions in your shop still travel by email and memory, book a free 20-minute Data Health Check and we will look at where the handoffs break.

A FileMaker ERP for a manufacturer should cover seven connected jobs: quoting, orders, inventory, work orders, purchasing, shipping, and job costing, all reading from one shared record. You build them in stages, but you plan for all seven from the start. Everything else can wait until those seven run cleanly, and accounting can stay in the package you already use.

Here is a Tuesday morning we hear about often. A customer calls the operations manager asking when their order ships. She checks the order spreadsheet, walks to the floor to ask the lead which step the job is on, then emails purchasing to find out if the bar stock arrived. Three sources, three answers, and none of them agree with the whiteboard.

An ERP (enterprise resource planning system, software that ties sales, production, inventory, and purchasing into one record) exists to fix exactly that. The question is what yours needs to do.

Scope the FileMaker ERP around how your shop runs

Packaged ERP systems are built to cover every kind of manufacturer. That can leave you configuring around screens you never use while the workflow that makes your shop different stays in a side spreadsheet. A custom build starts from how work actually moves through your building. We have written about building a custom ERP around manufacturing workflows; this post is the scope checklist.

The seven modules that carry the day

Each module hands its data to the next. Miss a link and someone rekeys it.

• Quoting. Material, setup, run time, outside processing, and margin in a repeatable model. An accepted quote becomes the order without retyping.
• Orders. One record per customer order with part, revision, quantity, promise date, and status. This is where the “when does it ship” question gets answered.
• Inventory. On hand, allocated, and on order for each item, with every receipt, issue, and adjustment logged so the count on screen matches the shelf.
• Work orders. The job traveler in digital form: operations, routing, materials to pull, and who completed each step. This is also where WIP (work in process, jobs started but not finished) becomes visible.
• Purchasing. Purchase orders tied to the jobs or stock levels that triggered them, with expected dates feeding order promise dates.
• Shipping. Pick, pack, and ship against the order, with tracking on the same record customer service reads.
• Job costing. Estimated versus actual material, labor, and outside services per job, so the next quote learns from the last one.

Why does one source of truth matter more than any single module?

Now the same Tuesday, after the build. The operations manager opens the order. She sees the work order is at deburr, the bar stock has arrived, and the ship date still holds. One screen, one answer.

That only works because the modules share records instead of passing files:

Quote accepted

↓

Order created with the quoted part and price

↓

Work order generated, materials allocated

↓

Shortages raise a purchase order

↓

Job completes, shipment recorded

↓

Actual costs roll up against the original quote

The integration between your ERP and CRM follows the same rule. Customer data lives in one place and every module reads it from there.

What can wait until phase two?

Reasonable candidates for the roadmap rather than the first release:

• MRP (material requirements planning, automated forecasting of what to buy and when) until you trust your inventory counts.
• Finite scheduling (planning jobs around real machine and shift capacity), once work orders are reliably tracked.
• Quality and nonconformance tracking, unless a customer or certification requires it now.
• Portals and dashboards beyond the few reports you check daily.

These all depend on clean data from the core seven, and they are far easier to build once that data exists.

Build first where money leaks today

A staged build usually works better than a big-bang cutover (switching everything over on one date): each stage proves itself before the next begins, and your team learns the system a piece at a time. Let the money set the order.

• If jobs regularly lose margin and nobody knows why until month end, start with quoting and job costing.
• If customers call to ask where their order is, start with orders and work orders.
• If you expedite material or find stock you already owned, start with inventory and purchasing.

Pick the costliest leak, run that module for a few weeks, then connect the next. Our earlier piece on why FileMaker is an inexpensive alternative to packaged ERPs covers the cost side of that choice.

Where does accounting fit?

Keep it where it is. Your bookkeeper knows QuickBooks (or whatever you run), your accountant reviews it, and rebuilding a general ledger adds risk without adding value. The ERP handles operations, the accounting package handles the books, and an integration carries customers, invoices, and vendor bills between them so nobody types an invoice twice. Claris documents a QuickBooks connector in Claris Connect, its integration service, with actions such as creating customers, invoices, and purchase orders. Plug-ins and direct API connections are other options, and the right one depends on which edition of QuickBooks you run.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We scope FileMaker ERP builds module by module, starting with the one that is costing you the most today.

Frequently asked questions

Can FileMaker be used as an ERP for a manufacturing company?

Yes. FileMaker can run quoting, orders, inventory, work orders, purchasing, shipping, and job costing in one connected system. It is one option among several; the bigger decision is scoping around how your shop works.

Do we have to replace QuickBooks to use a FileMaker ERP?

No. Accounting can stay in the package you already use, and an integration connects the two so customers, invoices, and bills are not entered twice.

How long does it take to get the first module running?

It depends on the module and how clean your existing data is. A staged approach puts one module into daily use before the next begins.

If you want a second set of eyes on where your data is breaking down, book the free 20-minute Data Health Check.

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.

The best way to pass a customer manufacturing quality audit is to make traceability part of normal production. Connect each job to its material lots, inspections, process records, certificates, and approved revisions as the work happens. Then an audit request becomes a search and review, not a week of reconstructing evidence.

Good documentation does more than satisfy an auditor. It shows a customer that the shop can control repeat work and respond when something goes wrong.

The audit request arrives on Tuesday

A major customer asks for the material certification, inspection results, and process history for three shipments. The quality manager knows the records exist, but not in one place.

One certificate is attached to a receiving email. Inspection results are in a workbook. The traveler is in a file cabinet. A revised drawing is on the shared drive, but the team cannot immediately prove which revision production used. The request is due Friday.

People stop their ordinary work to search. The quality manager becomes the coordinator for a system that should already know the answer.

Kyo’s article on automating certificates of conformity and test reports shows how structured job data can make required outputs repeatable.

Traceability should start before production

Audit readiness begins when the order and specification enter the system. The job should identify the customer requirement, approved drawing or specification revision, required inspections, material rules, and any documents that must follow the shipment.

Material receipt

↓

Lot or heat recorded and documents attached

↓

Material issued to a specific job

↓

Operations and inspections recorded

↓

Shipment package generated from the job record

This chain creates context. A certificate is not merely a PDF in a folder. It is evidence for a specific received lot that was used on defined jobs and shipments.

Kyo covers the material side in tracking raw materials, formulas, and processes. The system must preserve the identifiers that matter to the company’s products and customer obligations.

What should the job record prove?

A review-ready job record should make it practical to answer:

• Which customer order and specification governed the work?
• Which material lots or batches were consumed?
• Which operations were completed, by whom, and when?
• Which inspections were required and what were the results?
• Which nonconformances, deviations, or rework events occurred?
• Which certificates and reports accompanied the shipment?

The exact evidence depends on the contract, industry, and quality system. Software should support those requirements, not invent them. The quality team owns the procedure and retention rules; the application makes consistent execution and retrieval easier.

How does documentation become a sales advantage?

A customer does not want a polished audit day followed by unreliable daily work. It wants evidence that the supplier can reproduce the same control on the next order.

Fast retrieval sends a clear signal. When the customer asks about a lot, the team can produce the job, material, inspection, and shipment chain without improvising. When a correction is needed, the shop can identify affected work and respond with scope instead of uncertainty.

That credibility supports renewals and larger contracts. Kyo’s article on manufacturing CRM and compliance standards explains why quality history belongs in the customer relationship, not only in a quality folder.

Start with the hardest record to retrieve

Choose one recent shipment and try to reconstruct its evidence as an auditor would. Time each step. Note where the chain depends on a person’s memory, an email search, or an ambiguous filename.

Then fix the highest-risk break. That may be material-lot capture, revision control, inspection completion, or document generation. Use required fields and status gates carefully, so the system prevents missing evidence without encouraging people to enter meaningless placeholders.

Test normal exceptions too: substituted material, split lots, partial shipments, rework, and a revised specification after release. An audit-ready system needs to tell the truth when the path is not tidy.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We turn existing quality procedures into connected workflows that make evidence easier to capture, review, and retrieve.

Frequently asked questions

What records do customers usually request during a quality audit?

Requests may include specifications, material certificates, lot traceability, inspection results, process records, training evidence, nonconformance records, and shipment documents. Contract and quality requirements determine the exact set.

Does software make a manufacturer compliant?

No. Software can support controls and evidence, but compliance depends on applicable requirements, procedures, execution, oversight, and validation.

Should audit documents be stored separately from job records?

Files may live in a document store, but the system should maintain a reliable relationship between each document and the job, material, inspection, or shipment it supports.

Pick one shipped job and bring it to a free 20-minute Data Health Check. We will trace its audit evidence with you and show where the trail breaks.

Yes. FileMaker can serve as a capable manufacturing CRM when customers, quotes, jobs, and service history already live in the same custom application. A separate CRM makes more sense when the company needs specialized sales automation, marketing operations, or enterprise capabilities that should remain outside the production system.

The right answer depends on what “CRM” means to the team. For a manufacturer, customer relationships are often inseparable from operational performance.

A manufacturer’s CRM needs more than contact notes

A generic CRM usually centers on leads, opportunities, activities, and pipeline. Those records matter, but an account manager at a custom manufacturer also needs answers from the shop.

What did this customer order last year? Which drawing revision governed the current job? Did the last three orders ship on time? Is a quality issue still open? Which quote resembles the new request, and was that work profitable?

When FileMaker already holds the jobs and quotes, a customer record can connect those facts without copying them into a second product.

Customer and contacts

↓

Opportunities and quotes

↓

Jobs, requirements, and production status

↓

Shipments, issues, and follow-up

The CRM becomes a record of the working relationship. Sales sees operational truth in an appropriate view, while production keeps control of the detailed workflow.

What should a FileMaker manufacturing CRM include?

Start with the work the team performs, not a checklist from a software comparison page:

• Account, location, and contact relationships.
• Opportunities, next actions, ownership, and expected value.
• Quote history, versions, assumptions, and outcome.
• Open jobs, current promise status, and relevant exceptions.
• Customer requirements, documents, and communication history.
• Service issues, corrective actions, and follow-up commitments.

FileMaker can present these records through role-specific layouts and scripted workflows. The exact security model, mobile behavior, integrations, and performance should be validated for the solution and current FileMaker version.

Kyo’s article on integrating ERP and CRM for manufacturing shows why connected operational and customer data gives the team a more useful picture than two isolated dashboards.

Data quality decides whether the CRM is trusted

A custom CRM can still fail if every department creates its own version of the same account. Define matching rules, ownership, required fields, and review paths for suspected duplicates. Preserve useful history when records merge.

The process should handle common problems:

• The same company appears under a legal name and a trade name.
• A contact moves to another customer.
• Two salespeople create the same prospect.
• Shipping and billing addresses are treated as separate accounts.
• Imported lists contain stale or incomplete records.

Kyo’s detailed guide to CRM cleanup in FileMaker covers standardizing, merging, and validating the data before automation multiplies the mistakes.

When should a manufacturer buy a separate CRM?

A dedicated CRM may be better when the company has a large sales organization, sophisticated territory and compensation rules, mature marketing automation, many external sales integrations, or a corporate standard shared across multiple business units.

The system should earn its separation. Define which product owns each shared fact. The CRM may own leads, opportunities, and sales activity. FileMaker may own accepted quotes, jobs, and production status. Customer identity and status changes need a controlled exchange with monitoring for failed or duplicate transfers.

Do not let both systems casually edit the same fields. That creates a daily sync argument the business must resolve.

Kyo’s article on tailoring CRM systems for manufacturing compliance adds another consideration: permissions, customer requirements, and evidence may need to cross the boundary without exposing unrelated operational data.

How should you decide?

Map one customer relationship from first inquiry through repeat order. List the questions each role needs to answer and the source for each answer. Then identify the workflows that are unique to the company and the capabilities that are genuinely standard.

Use FileMaker as the CRM when the value comes from connecting customer work to the custom operational model. Use a separate CRM when its specialized sales capabilities outweigh the cost of integration and ownership.

The goal is not to replace a useful platform. It is to put each responsibility in a system the business can govern.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We help manufacturers extend the FileMaker systems they already trust and connect a dedicated CRM when the business case calls for one.

Frequently asked questions

Is FileMaker CRM software?

Yes. Many manufacturers run their CRM in Claris FileMaker. Because it is a custom application platform, a development team builds the CRM around the company’s own customers, quotes, and jobs, and connects it to other operational workflows.

Can FileMaker track opportunities and sales activity?

Yes, a solution can model opportunities, ownership, stages, tasks, communication, quotes, and related records. The design should reflect the company’s sales process.

Can FileMaker connect to a separate CRM?

Often, yes. The integration method depends on the CRM, available APIs, authentication, data ownership rules, and monitoring requirements.

Not sure where your customer data should live? Book a free 20-minute Data Health Check, and we will map what your system already knows about each customer.

Preventive maintenance tracking does not have to live in its own software. For many manufacturers, the simplest working version is a maintenance record inside the system that already runs jobs and schedules, so the next service window shows up right next to the work it will interrupt.

Picture the second-shift lead on a Thursday night. The spindle on the older horizontal mill starts to whine. The service sticker is faded, the clipboard by the machine stops in June, and the tech who keeps it all in his head is on vacation. Friday’s hot job is scheduled on that mill.

That is the problem this post is about. Not a missing app. A missing record.

Paper and memory fail at the worst possible moment

Most shops already do preventive maintenance. The trouble is that the record lives in three places: a sticker on the machine, a binder in the office, and one experienced person’s memory.

Someone has to remember the interval. Someone has to find the binder. Someone has to notice that a machine running double shifts hits its hour-based service twice as fast as the calendar suggests. When any link breaks, preventive maintenance quietly becomes reactive maintenance, and that always lands on the busiest week.

What does a minimum maintenance record need?

A useful preventive maintenance record answers five questions:

• Asset: which machine, press, compressor, or fixture, with a unique ID you can put on a tag.
• Interval: how often the task is due, by calendar days, run hours, or cycles.
• Last done: the date (or meter reading) of the most recent completed service, and who did it.
• Next due: calculated from the interval, not typed by hand, so it cannot drift.
• Parts and supplies: the filters, belts, or lubricants the task consumes, so they are on the shelf before the window opens.

Add a checklist per asset and a notes field, and you have a history that survives vacations and retirements.

Maintenance windows belong on the production schedule

When the next-due date for the mill lives in the same place as the jobs booked on the mill, the conflict is visible before it happens.

A basic flow might look like this:

Asset reaches its interval (date, hours, or cycles)

↓

Maintenance task appears as “due soon” with a target window

↓

Scheduler sees the window beside the jobs booked on that machine

↓

Planned downtime is placed between jobs, not in the middle of one

↓

Completed task resets the next-due date automatically

If your system already captures run time or cycle counts, as described in Kyo’s post on gathering real-time production statistics, usage-based intervals can be driven by actual machine use instead of a guess. Overdue tasks can then surface the same way other problems do, on an exception view for orders and inventory that shows only what needs attention today.

Check-offs should happen at the machine, not at the desk

If the tech has to walk back to an office PC after every task, entries get batched at the end of the shift and details get lost.

Mobile check-off fixes that. The tech scans a tag on the machine, the right task list opens, they tick off each step, snap a photo of the worn belt, and sign. No paper form. No photo hunt. No duplicate entry.

This works on several platforms. If you run Claris FileMaker, it is one practical option: Claris documents that FileMaker Go’s Insert from Device script step can capture photos, scan barcodes, and collect signatures on an iPhone or iPad. Kyo’s post on mobile capture with photos, signatures, and QR codes walks through what that looks like in practice.

When is a standalone CMMS worth it?

A CMMS (computerized maintenance management system) is software built specifically to plan, track, and document maintenance work. For some operations it is exactly the right call.

A dedicated CMMS often makes sense when:

• You have a full maintenance department with its own planners and a large, complex asset base.
• You need deep spare-parts inventory management, vendor service contracts, and maintenance cost accounting.
• Regulators or customers require formal maintenance documentation and reporting that a purpose-built package already handles.
• Maintenance runs largely independent of production scheduling.

It is often more than you need when a couple of techs handle maintenance alongside other work, the asset list fits on a page or two, and the real pain is visibility rather than planning depth. Then a separate system adds another login and another set of data that does not talk to your schedule. The better fit is usually extending what already works.

How do you know it is paying off?

Track these from the record itself:

• Unplanned stops per month on the machines you put on a schedule.
• Percent of tasks completed on time versus overdue.
• Jobs rescheduled because of a breakdown.

Give it a quarter and watch the trend move from surprise to plan.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We help shops put maintenance records next to the production schedule so planned downtime stops colliding with promised work.

Frequently asked questions

Can we track preventive maintenance in a spreadsheet?

You can start there, but spreadsheets struggle with usage-based intervals, mobile check-offs, and per-asset history. Most shops outgrow them once more than one person updates the file.

Should intervals be based on calendar time or machine hours?

Use whatever the equipment manufacturer recommends for each task. Many machines need both: some tasks by calendar, others by run hours or cycles. Your record should support either.

What if we already have some maintenance history on paper?

Enter the most recent completed service per asset to set accurate next-due dates. Scan and attach older history later if audits or warranty claims need it.

Not sure what your current data can support? Book a free 20-minute Data Health Check and we will take a look together.

You can get reliable shop-floor visibility without buying a full ERP. A focused custom app can connect each job to its materials, operations, costs, and current status, giving the team one place to answer where the work is, what it is costing, and whether it will ship on time.
The value is not a prettier production board. It is a record that changes as the work changes.

A job traveler should not disappear into the shop

Job 4521 starts with an approved quote and a promised date. Planning releases the traveler. Material moves to cutting. The first operation finishes, but the paper traveler waits on a cart. The schedule still says the job is in cutting. Sales tells the customer everything is on track because no one has reported a problem.
At inspection, the team finds a dimensional issue. Two parts need rework. The note goes on paper, the cost goes nowhere, and the promise date becomes a guess.
A visible system records each transition where it occurs. The operator does not write a status in one place and ask someone else to update another. Starting, pausing, completing, scrapping, and moving material are the events that build the current picture.
Kyo’s article on gathering real-time production statistics explains why the useful report begins with reliable activity capture.

Can the shop answer three basic questions?

Every production system should answer:

Where is the job? Show the current operation, work center, queue position, and blocker.
What is it costing? Connect labor, material, outside services, scrap, and rework to the job.
Will it ship on time? Compare remaining work, required material, capacity, and the promise date.

Spreadsheets often answer one question at a time. A schedule may show dates but not material shortages. An inventory file may show quantity but not what is reserved. A costing sheet may be complete only after the job closes.
Visibility comes from relationships. Job 4521 should point to its operations, material demand, actual issues, quality results, and shipment. Each screen can stay simple because the records underneath are connected.

What does one source of truth look like?

Quote becomes job
↓
Job creates operations and material demand
↓
Shop activity updates status and actual cost
↓
Exceptions appear before the promise is missed
↓
Shipment closes the operational record
Materials belong in that flow. When receiving records a delivery, available inventory changes. When a job pulls material, on-hand and job cost change together. When unused material returns, both records are corrected through a controlled transaction.
Kyo covers that pattern in real-time inventory tracking. The point is not to make the number move faster. It is to make the movement explainable.

Build the screens around work, not around tables

An operator needs a short queue, clear instructions, required documents, and a fast way to report the result. A planner needs capacity, shortages, blocked work, and late-risk indicators. Sales needs a customer-facing status without access to internal production details.
One application can provide those different views while keeping one underlying job record. That is more useful than forcing every role into the same crowded dashboard.
The workflow also has to allow real exceptions. A job may skip an operation, return for rework, split into partial shipments, or wait on customer approval. Kyo’s article on customizing production steps and requirements shows why the system must reflect how the shop actually routes work.

Start with one value stream

Do not begin by digitizing every form in the building. Pick one product family or work center where visibility is poor and the business effect is clear. Define the status events, material transactions, and exceptions that matter. Pilot them with the people doing the work.
Measure practical outcomes: fewer status-chasing messages, earlier shortage detection, more accurate job cost, and fewer late surprises. Small production issues become large delays when the system hides them until the schedule is already broken.

Frequently asked questions

Do we need an ERP to track production in real time?

No. A focused application can capture production events and report current status. The right architecture depends on volume, integrations, devices, and availability requirements.

How does a custom app know where a job is?

Operators or connected equipment record defined events such as start, pause, complete, move, inspect, or ship. Those events update the job’s current state.

Can the app track materials with the job?

Yes. Receipts, reservations, pulls, returns, and scrap can be modeled as transactions tied to the job and inventory item.

What should we pilot first?

Choose a workflow with frequent status questions or costly late surprises, and include normal exceptions rather than testing only the ideal path.

Where to start

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We design shop-floor tools around the decisions each role makes, then connect those views to one controlled operational record.

If your team cannot answer where a job is without walking the floor, talk with Kyo Logic about a focused visibility pilot.

Disconnected manufacturing tools cost more than their subscription fees. When an order lives in QuickBooks, spreadsheets, email, and a whiteboard, the shop pays through duplicate entry, stale status, preventable expediting, and decisions made from conflicting information. A connected custom system reduces that tax by giving each business event one controlled home.
The problem is easy to miss because each tool works on its own. The cost appears in the spaces between them.

One order lives four different lives

A customer emails a revised purchase order. Sales updates the quote spreadsheet. Production is already using a printed traveler based on the first version. Purchasing has material demand in another workbook. Accounting creates the customer order in QuickBooks using the new quantity but the old promised date.
Nothing looks broken in isolation. Every file opens. Every team can point to a record. Yet the company no longer has one answer to a basic question: What did we promise?
Someone forwards the email.
Someone updates the traveler.
Someone finds the mismatch after material has been cut.
Kyo’s article on misaligned sources of truth in manufacturing explains why these conflicts become operational risk, not merely administrative inconvenience.

What does the disconnected-tools tax include?

Rekeying time. The same customer, part, quantity, and date are entered in multiple places. That work creates no new value and introduces opportunities for error.
Version disputes. People spend time proving which spreadsheet, attachment, or message is current. Decisions wait while the team reconstructs history.
Late exceptions. A shortage or delay sits inside one tool until someone manually carries it to the person who can act.
Unreliable costing. Material, labor, rework, and outside services arrive on different schedules. The real margin appears after the team has already quoted the next job.
Customer trust. Sales gives an answer based on the system it can see. Production knows something different. The customer experiences the mismatch.
One more spreadsheet often feels cheaper than changing the process. Kyo’s piece on when one more spreadsheet becomes a bottleneck shows when that trade stops working.

Why is a bigger ERP not automatically the fix?

An enterprise ERP can connect broad business functions, but it also brings a broad implementation. A custom manufacturer running quotes, jobs, and materials across separate tools may need a focused system for quote-to-job flow, shop status, materials, and exceptions, while keeping accounting or another specialized product in place.
Replacing four disconnected tools with one oversized system can trade one problem for another. If the workflows do not match the shop, people rebuild the old process in side spreadsheets.
The better starting question is: Which facts must remain connected from the customer’s request through shipment? Build or select the system around those facts and define clean boundaries with every tool that remains.

What would a connected custom system change?

Customer revision received
↓
Controlled order version updated
↓
Material demand and production plan recalculate
↓
Affected roles see the exception
↓
Customer promise is confirmed or changed
The app does not need to perform every function. It needs to make ownership clear. Accounting can remain authoritative for financial transactions. The custom system can own the operational job, material requirements, and status. The integration should pass defined facts with a visible failure queue.
Kyo’s article on FileMaker as an affordable ERP alternative gives another view of how smaller manufacturers can buy the control they need without adopting enterprise weight.

Measure the cost before choosing the cure

For two weeks, track how often people re-enter the same data, ask for status, correct a mismatch, expedite material, or discover a change late. Record the minutes and the business effect. Include supervisors and operators, not only office staff.
That evidence shows where connection matters first. It may point to one workflow, such as order revision control, rather than a complete system replacement. A bounded first project is easier to test and more likely to earn adoption.

Frequently asked questions

What are disconnected manufacturing tools?

They are systems or files that hold related operational information without a reliable shared record or controlled exchange.

Are spreadsheets always a problem in manufacturing?

No. Spreadsheets are useful for analysis and temporary work. Risk rises when they become the authoritative system for a shared, changing operation.

Does a connected system have to replace QuickBooks?

No. Accounting can remain in QuickBooks while a custom operational system manages jobs, production, and material flow through a defined integration.

How can we estimate the hidden cost?

Track duplicate entry, correction, status-chasing, expediting, and late discovery for a representative period, then attach labor and business impact to each event.

Where to start

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We connect the records and handoffs that run the shop while preserving the systems that still do their jobs well.

If the same order has a different answer in every department, contact Kyo Logic to map the smallest connected workflow that would remove the conflict.