Tag: Claris Studio

Using Claris Studio as a Reporting and Action Layer on Top of FileMaker

Posted on by Kyo Logic

Not every dashboard needs a BI project

A lot of operational reporting falls into an awkward middle ground.

It is too dynamic and work-oriented to live comfortably in static exports. It is too immediate and tactical to justify a full separate BI initiative. And it often needs to sit close to action, not just observation.

That is where Claris Studio becomes interesting as a reporting and action layer on top of FileMaker.

Studio supports dashboard and custom views, along with list-detail, kanban, spreadsheet, timeline, calendar, and other view types. Once FileMaker data is connected as a Studio data source, it can be used just like native Studio data.

The difference between reporting and operational reporting

This distinction matters.

Executive or analytical reporting usually asks questions like:

  • What happened over time
  • What is the trend
  • What should leadership know

Operational reporting asks questions like:

  • What needs action right now
  • Where is work stalled
  • Which items are aging
  • Who owns the exception
  • What must move today

Those are different jobs. And they usually require different surfaces.

A good example: the order exception desk

This is a strong use case because it combines summary, queue management, and direct action.

A FileMaker system may already hold the core data:

  • orders
  • exception types
  • customers
  • owners
  • due dates
  • resolution timestamps
  • notes
  • escalation status

The challenge is often not storing the data. It is making the current situation visible and actionable without forcing every user into a deeper operational app than they need.

A practical architecture

FileMaker application

– Orders

– Exceptions

– Customers

– Owners

– Resolution rules

– Scripts

       ↓

Claris Studio data source

       ↓

Studio views

– Dashboard view for counts and trends

– Spreadsheet view for triage

– List-detail view for review

– Kanban view for status movement

       ↓

Optional automation

– FileMaker scripts

– Claris Connect notifications

This works best when Studio is used for lightweight action and visibility, while FileMaker remains responsible for the deeper rules.

Start with decisions, not charts

A reporting layer becomes useful when each metric is tied to a real decision.

For an exception desk, useful operational questions might be:

  • How many open exceptions are older than 48 hours
  • Which owners have the largest unresolved queues
  • What exception types are growing this week
  • Which branch or region is generating the most rework
  • What should be escalated today

Those questions lead to stronger design than starting with a generic desire for “a dashboard.”

Expose the right derived fields from FileMaker

This is one of the most technical parts of the pattern.

If Studio is going to be a good operational surface, the source data should not force every view to re-derive meaning from raw fields.

It helps to expose calculated or script-maintained fields such as:

  • AgingBucket
  • PriorityBand
  • SLAStatus
  • DaysOpen
  • OwnerDisplayName
  • IsEscalated
  • LastActionAt
  • ActionNeededFlag

That makes dashboarding cleaner and helps keep the semantic logic closer to the source system.

A simple FileMaker calc example

For example, a status banding field might be as simple as:

Case (

   IsEmpty ( Exceptions::ResolvedAt ) and GetAsNumber ( Get ( CurrentDate ) – Exceptions::CreatedDate ) >= 5 ; “Critical Aging” ;

   IsEmpty ( Exceptions::ResolvedAt ) and GetAsNumber ( Get ( CurrentDate ) – Exceptions::CreatedDate ) >= 2 ; “At Risk” ;

   IsEmpty ( Exceptions::ResolvedAt ) ; “Open” ;

   “Resolved”

)

This is not sophisticated logic. That is the point. Small derived fields often make the reporting layer much cleaner.

Use the right Studio view for the right decision

A dashboard is useful for pattern recognition.

A spreadsheet view is useful for batch triage and filtering.

A list-detail view is useful for a reviewer who needs context on one record at a time.

A kanban view is useful when the team manages work visually by stage.

A timeline or calendar view is useful when operational timing matters.

Studio’s value here is that it lets those surfaces coexist over the same connected data.

Action should be lightweight and deliberate

A common mistake is to treat a reporting surface as if it should become a full transaction-processing UI.

Usually, the better model is to allow lightweight actions such as:

  • assign owner
  • change review status
  • flag for escalation
  • add a short note
  • mark ready for follow-up

But if an action depends on validation, multi-record updates, financial consequences, or strict privileges, it probably belongs in FileMaker.

That boundary is what keeps the architecture clean.

Separate operational action fields from core business fields

This is an underrated design principle.

Suppose a manager needs to push an exception into “Needs Escalation.” That does not necessarily mean they should directly modify the final business state field that drives downstream accounting or fulfillment behavior.

A safer pattern is to expose action-intent fields or controlled transitions, then let FileMaker handle the authoritative update.

For example:

Studio-facing field:

Exceptions::ActionRequest = “Escalate”

 

FileMaker logic:

If ActionRequest = “Escalate” and exception meets policy

   Set EscalationStatus = “Pending Review”

   Create escalation task

   Stamp audit trail

   Clear ActionRequest

End If

That reduces the risk of a web-facing surface becoming the place where core business rules get bypassed.

Scale and sync still matter

Claris documents that FileMaker-connected tables in Studio can import up to 250,000 records at a time, but changes to tables larger than that threshold will not sync.

That suggests a practical design rule: Studio is strongest as an operational slice, not as a place to dump every historical record in the business.

For an exception desk, that usually means:

  • current open work
  • recent closed work
  • targeted rollups
  • filtered operational cohorts

It is usually a bad idea to aim Studio at every transaction your system has ever held.

Governance matters more than the charts

Because Studio can publish responsive views and can support both named and anonymous sharing scenarios, governance should be explicit.

That means deciding:

  • Which fields are safe to expose
  • Which users can act versus only view
  • Which hubs belong to which audiences
  • Whether any temporary public access is appropriate
  • What the fallback workflow is when deeper action is required

A dashboard without governance is just another reporting liability.

When this pattern is strongest

This architecture works particularly well when:

  • teams need current operational visibility
  • work is managed in queues, stages, or ownership buckets
  • users need lightweight action from the same surface
  • the existing FileMaker app is too broad for every user to live in full time

It is less compelling when:

  • The use case is highly analytical and historical
  • The reporting layer needs complex dimensional analysis
  • The workflow requires dense, high-trust transaction entry
  • The dataset is too large and too broad to expose operationally in Studio

Closing thought

The best way to think about Claris Studio here is not as a replacement for FileMaker reporting and not as a replacement for BI.

It is a middle layer.

A place where operational data becomes visible, navigable, and lightly actionable, while the deeper system of record remains in FileMaker.

That is a more useful and more implementable framing than “build a dashboard.”

If you want, next I’ll turn these into polished, publication-ready drafts with a more Kyo-native voice, tightened intros, strengthened conclusions, and light CTA language at the end of each post.

How to Connect FileMaker Data to Claris Studio Safely and Design Around Sync Limits

Posted on by Kyo Logic

Claris Studio is more useful when you stop treating it like a separate island

A key change in the Claris platform is that Claris Studio now connects directly to FileMaker data sources, including FileMaker Cloud. This makes it practical to extend FileMaker workflows to the web without duplicating your data in another system. However, not every FileMaker table should be shared with Studio, and you cannot ignore the sync model. Claris provides clear guidelines on sync behavior, offline scenarios, and scalability. So, instead of asking, “How do I connect FileMaker to Studio?” it is better to ask, “Which data should I connect, and under what rules?”

The strongest Studio use cases typically involve an operational slice of your FileMaker system rather than the entire database.

Good candidates tend to be datasets like:

  • Open service requests
  • Approval queues
  • Project summaries
  • Order exceptions
  • Active work assignments
  • Current operational dashboards

These work well because they are current, bounded, and easy to present through Studio views. Claris notes that up to 250,000 records can be imported from FileMaker data sources at a time, but changes to tables larger than that will not sync. That alone is a good reason to avoid aiming Studio at every historical record you own. r as the source of truth

If you are connecting FileMaker data to Studio, the safest architectural assumption is that FileMaker remains the authoritative system.

That means core business rules, transactional logic, audit-sensitive changes, and exception handling should continue to live primarily in FileMaker. Studio is best used as a web-facing interaction and visibility layer on top of that source data. This fits how Claris describes Studio overall: a cloud environment for creating rich web experiences while keeping the same data available to FileMaker apps for reading and writing. Simple: if a change has financial, legal, or cross-record consequences, keep the enforcement in FileMaker.

Build around operational slices, not raw table dumps

A common mistake is to connect a large table and assume the Studio view will sort itself out later.

A better pattern is to decide first what the Studio experience is for, then expose the FileMaker data needed for that slice. For example:

  • A manager dashboard showing only open items
  • A field team workspace showing only assigned records
  • An exception desk showing only unresolved issues
  • An executive rollup showing only the summarized current activity

This usually leads to a cleaner experience and a safer sync model. It also makes it easier to stay within the practical record limits Claris documents for FileMaker-connected tables in Studio. ut offline and restart scenarios

This is the part many blog posts skip, but it is one of the most important implementation details.

Claris documents that if a FileMaker Server host used for a Studio data source is restarted or temporarily disconnected, and records are edited in both Claris Studio and FileMaker while the host is offline, recent changes can be lost.

FileMaker takes precedence, so Studio-side edits made during the outage can be overwritten once the host comes back online and data sync resumes. implications:

  • Avoid treating Studio as the place for high-risk concurrent edits on sensitive records
  • Be careful with workflows where many users may edit the same record from both sides
  • think twice before exposing fast-moving, heavily edited tables without a clear ownership model

If the workflow is concurrency-heavy, that is a warning sign to keep the critical edit surface in FileMaker.

Use derived fields to make Studio views cleaner

Studio becomes much more effective when it is not forced to infer operational meaning from raw fields alone.

It often helps to expose FileMaker-calculated or script-maintained fields, such as:

  • priority band
  • SLA status
  • aging bucket
  • owner display name
  • open versus resolved flag
  • escalation status
  • last action timestamp

These make Studio views easier to build and easier for users to interpret. They also keep business meaning closer to the FileMaker source, where it is easier to govern.

Pick the Studio view based on the job

Once the data source is connected, the next design decision is the view.

Claris Studio supports several view types, including spreadsheet, form, list-detail, kanban, and more. Those should not be chosen based on aesthetics. They should be chosen based on the kind of work a user needs to do.

  • A list-detail view is strong for one-record-at-a-time review.
  • A kanban view is strong for a stage-based workflow.
  • A dashboard is strong for bottlenecks and summaries.

The goal is not to rebuild your entire FileMaker layout in Studio. Instead, focus on creating a targeted workspace.

A practical implementation pattern

A safe first pattern looks like this:

FileMaker

– source tables

– business rules

– calculated helper fields

– scripts for critical actions

       ↓

Connected FileMaker data source in Claris Studio

       ↓

Studio views

– manager dashboard

– triage spreadsheet

– reviewer list-detail

       ↓

Optional hubs for audience-specific sharing

This approach keeps your main system stable while allowing you to add simple web-based features.

Where this approach fits best

Connecting FileMaker data to Studio is especially useful when:

  • You need a modern web-facing workspace quickly
  • Different audiences need different views of the same current data
  • The process is operational rather than deeply transactional
  • The value comes from visibility, filtering, lightweight edits, or coordination

It is less attractive when:

  • The dataset is extremely large and broad
  • The workflow depends on heavy concurrent editing
  • Complex transactional logic must run at the point of interaction
  • The Studio surface would become a second full application instead of a focused view

A better way to think about it

The safest and most useful Studio pattern is not “put FileMaker on the web.”

It is about choosing the part of your FileMaker data that benefits from a simpler web workspace, and then designing with the sync model in mind.

This makes Studio more practical and reduces the chance of hidden problems.

 

How to Build a Web Intake Workflow with Claris Studio, FileMaker, and Claris Connect

Posted on by Kyo Logic

Teams often ask for “an online form,” but that usually isn’t what they truly need.

What they really need is a workflow that collects information, checks it, sends it to the right place, adds details, updates records, and shows the current status to the right people.

This is why Claris Studio stands out when you see it as more than just a web form tool. You can share Studio forms with your team or anyone who has the link. Claris presents Studio as a platform for collecting, viewing, and analyzing data, which can also be used in custom apps.

For many implementations, the strongest pattern is:

  • Studio for capture
  • FileMaker for business logic and system-of-record behavior
  • Connect for orchestration and cross-system flow

A practical use case: vendor onboarding intake

Vendor onboarding is a good example because it has all the right ingredients:

  • external submission
  • inconsistent source data
  • duplicate risk
  • internal review
  • approvals
  • status tracking
  • follow-up tasks

That makes it better than a trivial demo.

The target architecture

Here is the core pattern:

External submitter

   ↓

Claris Studio form

   ↓

Claris Connect flow

   ↓

FileMaker

– validation

– dedupe

– vendor creation or update

– review tasks

– status management

   ↓

Claris Studio views/hubs

– intake queue

– review queue

– status visibility

This setup works well because Studio is great for easy, web-based data capture, while FileMaker is better for handling records and enforcing processes. Connect links the two when you need to move, change, or automate data.

Two valid data ownership models

Before building anything, decide where the real record begins.

Model 1: FileMaker-first
The Studio form writes into a FileMaker-connected data source, and FileMaker is the source of truth from the start.

Model 2: Studio-first, then promoted to FileMaker
The Studio form creates a Studio-side record first, and Connect later transforms that submission into operational records in FileMaker.

Both models can work. However, if your workflow involves important business data like vendors, clients, orders, or compliance records, starting with FileMaker is usually the safer choice for the long term.

Why Connect should be treated carefully

Claris Connect can be useful here, but the boundaries matter.

The Claris FileMaker connector works with hosted FileMaker apps and requires at least FileMaker Cloud or FileMaker Server 21.1.0. Claris also points out that the connector does not yet support direct access to Claris Studio tables. So, you should not expect one connector to handle every type of data in the same way.

Claris also documents that when working with FileMaker through Connect, the target app must have both Data API and OData privileges enabled, and those services must also be enabled on the host.

Details like this are important to highlight in a real implementation guide.

Design the schema before the form

A common mistake is building the intake form first and only later figuring out how the data fits into the system.

It’s better to define the operational schema before anything else. For a vendor onboarding workflow, a basic structure might be:

Intake_Request

– RequestUUID

– SubmittedAt

– SubmittedByName

– SubmittedByEmail

– CompanyNameRaw

– TaxIDRaw

– RequestType

– RawPayloadJSON

– ProcessingStatus

– ProcessingError

– RelatedVendorUUID

 

Vendor

– VendorUUID

– LegalName

– NormalizedTaxID

– PrimaryEmail

– Status

– CreatedAt

 

VendorContact

– ContactUUID

– VendorUUID

– FullName

– Email

– Phone

 

ReviewTask

– TaskUUID

– RequestUUID

– AssignedTo

– TaskType

– TaskStatus

– DueDate

 

StatusHistory

– HistoryUUID

– RequestUUID

– OldStatus

– NewStatus

– ChangedAt

– ChangedBy

Two fields here matter more than they may seem:

RawPayloadJSON gives you an audit-safe copy of exactly what came in.

ProcessingStatus and ProcessingError help you track the workflow, which is important when something goes wrong.

Build the Studio form for clean capture, not maximum data collection

Once you have the schema, designing the form gets easier.

A good intake form doesn’t try to gather every detail. It collects just enough clean information to start the process, leaving space to add more details later if needed.

That usually means:

  • Prefer controlled values over free text where possible
  • Separate public-facing labels from internal field naming
  • Avoid exposing operational fields on the intake form
  • Collect enough to deduplicate and route, not enough to re-create the entire back office

Studio forms can be shared broadly, including with anonymous users via a link, which is why form discipline matters.

A useful Connect flow pattern

Here is the shape of a practical flow:

Trigger: New intake record created

   ↓

Validate required fields

   ↓

Normalize values

– trim whitespace

– normalize email case

– strip punctuation from tax ID

   ↓

Check for existing vendor

   ↓

If vendor exists:

   update/attach to existing

Else:

   Create new vendor

   Create primary contact

   Create review task

   ↓

Write result back to intake record

– processed

– needs review

– duplicate found

– error

The real technical value isn’t in the visual flow, but in clearly separating each step.

Validation is not the same as normalization.
Normalization is not the same as deduplication.
Deduplication is not the same as approval.

The clearer you make these boundaries, the more reliable your workflow will be.

A FileMaker script parameter pattern worth using

When Connect or another process hands work to FileMaker, JSON parameters are usually cleaner than trying to overload single text parameters.

For example:

{

 “requestUUID”: “2C8A0A6E-85A3-4C3C-A8C0-41F9A88D4E10”,

 “submittedByEmail”: “ap@vendorco.com”,

 “requestType”: “New Vendor”,

 “source”: “Claris Studio”

}

Then the receiving FileMaker script can parse predictably:

Set Variable [ $requestUUID ; JSONGetElement ( Get ( ScriptParameter ) ; “requestUUID” ) ]

Set Variable [ $email       ; JSONGetElement ( Get ( ScriptParameter ) ; “submittedByEmail” ) ]

Set Variable [ $type        ; JSONGetElement ( Get ( ScriptParameter ) ; “requestType” ) ]

Set Variable [ $source      ; JSONGetElement ( Get ( ScriptParameter ) ; “source” ) ]

This isn’t advanced code, but it’s a reliable habit for implementation.

A dedupe pattern that is better than exact-match thinking

Relying only on exact matches is rarely enough for intake workflows.

A more useful pattern is to check some combination of:

  • normalized company name
  • normalized tax ID
  • primary email domain
  • known aliases or alternate names

This approach helps you handle different outcomes more effectively:

  • exact match, attach to existing
  • probable match, send to review
  • no meaningful match, create new

This is where FileMaker really proves its value. When cross-record logic is important, it’s best to keep the decision-making in the FileMaker app.

Make the workflow idempotent

This is one of the most practical lessons to include because many “working” intake flows fail here.

Never assume a submission is processed exactly once.

A safer design includes:

  • a stable external submission identifier
  • a processed timestamp
  • a processing status field
  • a retry-safe script or flow path
  • duplicate detection for the intake record itself

That way, if a flow retries or a user resubmits, the system can recognize the event without creating a mess.

Status visibility matters almost as much as capture

Once the workflow runs, Studio becomes useful again as the visibility layer.

You can create views or hubs that show:

  • Unprocessed intake
  • Duplicate review queue
  • Vendor setup in progress
  • Awaiting approval
  • Completed onboarding

That creates a much better operational surface than an email chain or a spreadsheet export.

Security and access notes

If you are using Connect with FileMaker, Claris documents that both Data API and OData access must be enabled appropriately. OData is a REST-based standard for querying and updating hosted FileMaker data, and the general OData workflow includes finding and modifying records, as well as running FileMaker scripts via API calls.

That does not mean every intake workflow should become an API-heavy project. It means your architecture should be intentional about privileges and integration points.

Closing thought

The right way to frame a Studio intake project is not, “How do we put a form on the web?”

It is, “How do we build a reliable intake pipeline?”

Studio gives you a clean web-facing start.

FileMaker gives you durable logic and operational control.

Connect gives you orchestration when the workflow needs to move, transform, or notify.

That is the version readers can actually implement.

 

Can Your FileMaker Do This? Add a ChatGPT/Claude Co-Pilot to FileMaker via MCP Protocol.

Posted on by Kyo Logic

Most teams assume “AI in FileMaker” means building a custom chat UI, wiring a bunch of APIs, and taking on a maintenance burden. With Model Context Protocol (MCP), you can flip that: use Claude as the interface, and expose a controlled set of FileMaker tools (tables, scripts, and actions) through Claris MCP.

What this looks like in practice

  • Calendar invites from records: “Create invites for next week’s site visits and include the customer address and scope,” then FileMaker generates the .ics details and logs it back to the record.
  • Data hygiene on demand: “Find duplicates created this month and propose merges,” then FileMaker runs your cleanup scripts and returns a review list for approval.
  • Planning and analysis without hunting: “Summarize last year’s customer trends and churn signals,” then the copilot pulls the right data and produces a narrative summary that links back to the underlying records.
  • Offline team catch-up: “What changed while the field team was offline?” The copilot then summarizes sync deltas and flags conflicts for review.

How it works

  1. You define a small set of “approved” scripts, such as CreateInvite, RunDataHygieneCheck, GenerateCustomerSummary, or BuildProductionPlanSnapshot.
  2. Claris MCP exposes only those tools, with permissions and scope you control.
  3. Claude calls those tools via MCP and returns results in plain English, optionally writing back to FileMaker through the scripts you allow.

Why it matters

  • Less time navigating layouts and rebuilding the same reports.
  • Faster follow-through, because the “answer” can include the next action (create invite, open task, generate summary) with an audit trail.
  • Low-risk rollout, because you can start read-only, restrict which scripts are callable, and log every request and response.

If you want a simple pilot, think through a single workflow that’s repeatable every week (consider: calendar coordination, duplicate cleanup, or executive summaries). Start by wiring up one or two approved scripts through MCP and prove value quickly, without changing your core system.

Need help? Don’t hesitate to contact us!

A Better Way to Extend FileMaker: Build Role-Based Workspaces with Claris Studio Hubs

Posted on by Kyo Logic

The old pattern works until it doesn’t

A lot of FileMaker systems start from a sensible place: one app, one schema, one interface, one source of truth. That works well when the audience is small and the process is mostly internal.

The friction starts when the same system must serve coordinators, managers, field staff, executives, and sometimes external participants. At that point, one large interface usually becomes a compromise. Some users see too much. Some see the wrong things. Some need only one narrow slice of the process, but still have to live inside a broader application built for someone else.

That is the mindset shift Claris Studio makes worth considering. In Claris Studio, a view is a way to present and work with data, and a hub is a collection of views shared with a specific audience. Studio supports multiple view types, including spreadsheet, form, list-detail, kanban, dashboard, list, gallery, timeline, and calendar.

A better mental model: one process, many surfaces

Instead of asking, “How do we make one FileMaker UI work for everyone?”, a better question is, “What surfaces does each role actually need?”

That leads to a cleaner architecture:

  • FileMaker remains the source of truth for core tables, relationships, calculations, scripts, and deeper business logic.
  • Claris Studio provides narrower, role-based workspaces built on top of the same operational data.
  • Hubs package those workspaces by audience, function, or responsibility.

This is not about replacing FileMaker. It is about reducing interface sprawl.

Where hubs fit particularly well

Hubs are a strong fit when a single process serves multiple audiences with different roles.

Think about a service operations workflow:

  • Coordinators need an intake queue and assignment surface
  • Field staff need only their work, dates, notes, and status updates
  • Managers need bottleneck visibility and SLA risk
  • Executives need roll-up reporting and trend snapshots

Those are not four versions of the same user. They are four different work contexts. Hubs let you reflect that reality.

A reference architecture

The simplest useful pattern looks like this:

[Users by role]

 Coordinators

 Field staff

 Managers

 Executives

       ↓

Claris Studio Hubs

 Intake Hub

 Field Work Hub

 Manager Hub

 Executive Hub

       ↓

FileMaker data source

       ↓

FileMaker application

 Requests

 Tasks

 Assignments

 Status history

 Business rules

 Scripts

 Notifications

Claris Studio can connect directly to FileMaker-hosted data sources, and once connected, FileMaker data can be used in Studio much like native Studio tables. That makes this architecture much more practical than it would have been if Studio had been thought of mainly as a separate form layer.

Start with the schema, not the screens

This is the part many teams skip.

If you want role-based workspaces to behave well, the underlying data model must support multiple audiences cleanly. That usually means separating operational entities more deliberately.

A common pattern would be:

Requests

– RequestUUID

– RequestType

– SubmittedBy

– Priority

– CurrentStatus

– OwnerID

– DueDate

– CreatedAt

– UpdatedAt

Tasks

– TaskUUID

– RequestUUID

– AssignedTo

– TaskType

– TaskStatus

– TaskDueDate

Assignments

– AssignmentUUID

– RequestUUID

– UserID

– RoleOnRecord

StatusHistory

– HistoryUUID

– RequestUUID

– OldStatus

– NewStatus

– ChangedBy

– ChangedAt

Users

– UserID

– Name

– Role

– Team

The important principle is simple: do not build your model around one screen. Build it around the process and its actors.

Match each role to the right view type

This is where Studio becomes useful in a very practical way.

A coordinator often needs a spreadsheet view because they are triaging, sorting, filtering, and making many small decisions quickly.

A manager often benefits from kanban or dashboard views because they are watching movement, backlog, and stalled work.

A field user may need list-detail or calendar because they care about only their assigned items and their due dates.

An executive typically needs summary views, not workflow-heavy surfaces.

Studio’s multiple view types matter because they let you express the same data differently without redesigning the core system every time.

What should stay in FileMaker

This is where many modernization projects go wrong. Once a web-facing surface becomes easier to build, people start pushing too much logic into the presentation layer.

A safer rule is:

Keep business logic in FileMaker when the action depends on cross-record validation, transactional behavior, privilege-sensitive updates, or exception handling.

That means things like these still belong primarily in FileMaker:

  • Status transition rules
  • Assignment logic
  • Escalation triggers
  • Deduplication
  • Creation of related records
  • Audit history generation
  • Downstream integrations

Studio should usually be the place where users see, filter, update, and collaborate. FileMaker should remain the place where the process is enforced.

A simple FileMaker example

Here is the kind of script logic that fits well in FileMaker, even if the user interaction starts in Studio.

Script: Apply Request Status Change

Set Variable [ $requestUUID ; JSONGetElement ( Get ( ScriptParameter ) ; “requestUUID” ) ]

Set Variable [ $newStatus   ; JSONGetElement ( Get ( ScriptParameter ) ; “newStatus” ) ]

Set Variable [ $userID      ; JSONGetElement ( Get ( ScriptParameter ) ; “userID” ) ]

Go to Layout [ “Requests” ]

Enter Find Mode [ Pause: Off ]

Set Field [ Requests::RequestUUID ; $requestUUID ]

Perform Find

If [ Get ( FoundCount ) = 1 ]

   If [ not IsValidStatusTransition ( Requests::CurrentStatus ; $newStatus ) ]

       Exit Script [ Text Result: “Invalid status transition” ]

   End If

   Set Field [ Requests::CurrentStatus ; $newStatus ]

   Set Field [ Requests::UpdatedAt ; Get ( CurrentTimestamp ) ]

   New Record/Request

   Set Field [ StatusHistory::RequestUUID ; $requestUUID ]

   Set Field [ StatusHistory::OldStatus ; Requests::CurrentStatus ]

   Set Field [ StatusHistory::NewStatus ; $newStatus ]

   Set Field [ StatusHistory::ChangedBy ; $userID ]

   Set Field [ StatusHistory::ChangedAt ; Get ( CurrentTimestamp ) ]

End If

The exact implementation will vary, but the architectural point is stable: keep the rules centralized.

Design hubs around work, not departments

A subtle mistake is to mirror the org chart too literally.

Sometimes the right hub is by department. Sometimes it is by phase of work, such as intake, review, fulfillment, and reporting. Sometimes it is by responsibility, such as my queue, approvals, escalations, and executive summary.

The strongest hub structures usually follow how decisions are made, not how the company draws its boxes.

Watch the sync and scale boundary

FileMaker-connected tables in Studio can import up to 250,000 records at a time. Claris also notes that changes or updates to tables with more than 250,000 records will not sync. That does not make Studio a bad fit, but it does mean this pattern is strongest when you expose the operational slice that matters, not every historical record in the system.

Claris also notes a practical sync concern: if the FileMaker host is temporarily offline, edits made in Studio while disconnected can later be overwritten when FileMaker comes back and takes precedence during sync.

That means you should be careful with heavily edited, large-scale, highly concurrent datasets.

Where this architecture shines

This pattern is especially strong when:

  • One core process serves several audiences
  • Some users need a lighter web experience
  • The FileMaker app has grown into a broad operational tool
  • Adoption is suffering because the interface is too wide for the job

It is less compelling when:

  • Every user truly needs the same deep interface
  • The workflow is mostly transactional and dense
  • The process depends on complex UI behavior that belongs inside FileMaker

Closing thought

The interesting opportunity with Claris Studio hubs is not that they give FileMaker a prettier front end. It is that they encourage better architectural discipline.

One process does not need one interface.

If your FileMaker system serves multiple audiences through a single broad UI, hubs are worth evaluating to split the experience without splitting the source of truth. 

Can Your FileMaker Do This: Real-Time Exception Desk for Orders & Inventory

Posted on by Kyo Logic

In the fast-paced world of business, operational hiccups, like late shipments, low stock, or missing paperwork, are inevitable. The challenge isn’t preventing them entirely, but catching and resolving them before they escalate into costly problems. This is where a real-time Exception Desk becomes an invaluable asset, transforming your FileMaker solution from a simple system of record into an active watchdog for your live data. By surfacing issues as they happen and guiding the right person to a swift resolution, an Exception Desk shortens the feedback loop, reduces surprises, and brings clarity and accountability to your order and inventory management.


What It Is

A lightweight Exception Desk watches your live data and flags issues as they occur. Late ship dates, stockouts, duplicate POs, missing documents, or out-of-range values are surfaced automatically in a clean dashboard. Each exception opens a small, guided workspace where the right person can acknowledge, assign, and resolve it.

Why It Matters

Most teams discover issues too late, often at the end of the day or week, when options are limited and context is lost. A real-time Exception Desk shortens the feedback loop.

  • Faster recovery with fewer surprises
  • Less email and spreadsheet back-and-forth
  • A clear audit trail of what happened, when, and who handled it, useful for stand-ups or customer conversations


How it Works (Conceptual Overview)

At a high level, the Exception Desk separates three concerns:

  • FileMaker acts as the system of record. It evaluates rules, creates exception records, and tracks status and ownership.
  • Claris Connect handles event-driven actions. When something important happens, it routes notifications, creates tickets, or contacts vendors.
  • Claris Studio provides a lightweight browser-based interface so occasional users can acknowledge or resolve exceptions without needing a FileMaker license.

This keeps core logic and data in FileMaker, while extending reach to the browser and other systems only where it adds value.


What’s Under the Hood (Simple Anatomy)

  • Rules stored as JSON in a Settings table, editable without schema changes
  • A combination of event-driven checks on record edits and a nightly baseline scan
  • An Exceptions log table with fields such as Type, Source Record ID, Status (Open, Assigned, Resolved), Owner, Notes, and Timestamp
  • A Studio form linked to the Exception ID for quick acknowledgement and resolution
  • One or more Connect flows that react to new or updated exceptions


Overview: A Simple End-to-End Example

To make this concrete, here is one realistic slice of the Exception Desk: a Stockout exception that is detected in FileMaker, routed through Claris Connect, and acknowledged in Claris Studio.

In this example:

  • FileMaker evaluates inventory levels and creates an Exception record when stock falls below a threshold.
  • Claris Connect reacts when that Exception becomes Open and sends a notification to Teams or Slack, optionally creating a ticket or emailing a vendor.
  • Claris Studio provides a small form where an operations user can acknowledge or assign the exception, writing directly back to FileMaker.

The examples below show the minimum touchpoints for this flow. They are not a complete solution, but they illustrate where each piece of logic lives and how the components connect.


Connect Example (High Level)

Flow: New Open Exception (Stockout)

  1. Trigger: When an Exception record is created or when Status changes to Open (via Data API or webhook).
  2. Filter: Type equals Stockout and Status equals Open.
  3. Actions: Post to Teams or Slack with a link back to the Exception, optionally create a ticket, then write back notification details to the Exception record.

 

Example Touchpoints (Sample Code to Adapt)

Note on sample code

These examples are illustrative. Update layout names, table occurrences, field names, and privileges to match your solution. Always check Get ( LastError ) and review results with JSONFormatElements ( $$result ) while testing.

A) FileMaker script fragment: evaluate a rule and open an Exception
Example: Stockout rule

If [ $QuantityOnHand < $MinStock ]
 New Record/Request [ Table: Exceptions ]
 Set Field [ Exceptions::Type ; “Stockout” ]
 Set Field [ Exceptions::SourceTable ; “Items” ]
 Set Field [ Exceptions::SourceID ; $ItemID ]
 Set Field [ Exceptions::Status ; “Open” ]
 Set Field [ Exceptions::Notes ; “Quantity on hand below minimum stock level.” ]
 Commit Records/Requests
 End If

B) One-step update with the Data API: acknowledge or assign an Exception

Execute FileMaker Data API [ Select ; Target: $$result ;
 JSONSetElement ( “{}” ;
 [ “action” ; “update” ; JSONString ] ;
 [ “layouts” ; “Exceptions_edapi” ; JSONString ] ;
 [ “recordId” ; $ExceptionRecordID ; JSONString ] ;
 [ “fieldData” ; “{ “Status”:”Assigned”, “Owner”:”Ops Desk” }” ; JSONObject ]
 )
 ]

C) Simple JSON rule pattern stored in Settings

Settings::ExceptionRulesJSON example:

{
 “rules”: [
 { “type”: “Stockout”, “expr”: “QuantityOnHand < MinStock” },
 { “type”: “LateShip”, “expr”: “ShipDate > PromiseDate” },
 { “type”: “DocMissing”, “expr”: “IsEmpty(COA_Received)” }
 ]
 }

Your script can read this JSON, evaluate expressions, and create Exception records when conditions are met. Many teams start with hard-coded rules and move to JSON as the system matures.


Quick “Try It” Plan (2–3 Hours)

  1. Define three starter rules, for example, QuantityOnHand < MinStock, ShipDate > PromiseDate, or missing documentation.
  2. Create an Exceptions table with a simple list and form layout in FileMaker.
  3. Add a Studio form with Status, Notes, and Assign To.
  4. Wire one Connect flow to notify Teams or Slack when an Exception opens.
  5. Pilot with one product line or warehouse for two weeks.

Where It Fits

  • Manufacturing and supply chain: stockouts, late suppliers, missing COAs or packing slips
  • Service and field work: missed appointment confirmations, parts not staged
  • Professional services: expiring SOWs, unapproved timesheets
  • Healthcare and education: missing forms, past-due follow-ups


Conclusion

Real-time exception handling is less about automation for its own sake and more about timing and accountability. When FileMaker remains the system of record, and Connect and Studio extend it outward, teams can respond while context still exists and before small issues become larger problems.


Many teams like the idea of an Exception Desk but prefer help designing and implementing it cleanly. If that’s you, Kyo Logic can help you scope and build this pattern around your existing FileMaker system. 

Cleaning Up Databases: How FileMaker Can Automate Data Hygiene

Posted on by Kyo Logic

As the year comes to a close, many organizations naturally focus on financial reporting and compliance. Another important opportunity during this time is reviewing the health of your data. Over the course of a year, databases can accumulate duplicate records, incomplete entries, outdated information, and small inconsistencies that gradually impact system performance and reporting accuracy.

With Claris FileMaker, organizations can automate data hygiene processes that clean, validate, and organize their databasesensuring systems are optimized and ready for the new year.

 

Automatically Identify and Remove Duplicate Records

Duplicate records are one of the most common data quality issues, especially in systems with multiple users, imports, or integrations. FileMaker scripts can automatically detect duplicates based on:

  • Matching email addresses or account IDs
  • Repeated SKU or product codes
  • Duplicate customer or vendor names
  • Identical timestamps or transaction references

Once identified, FileMaker can flag records for review, merge duplicates safely, or archive redundant entries, reducing clutter and improving accuracy across reports and workflows.

 

Validate Records and Enforce Data Standards

FileMaker excels at enforcing data validation rules, ensuring records meet your standards before the new year begins. Automated scripts can:

  • Identify missing required fields
  • Validate date ranges and numeric thresholds
  • Enforce formatting standards (emails, phone numbers, IDs)
  • Flag incomplete or inconsistent records

By running validation routines before January, teams avoid carrying bad data into a new reporting cycle.

 

Archive Old or Inactive Data Automatically

Not all data needs to remain part of your day-to-day operations forever. As systems evolve, older records can still be valuable for reference or compliance without needing to stay front and center. FileMaker scripts make it easy to archive:

  • Closed orders or completed projects
  • Inactive customers or vendors
  • Historical inventory records
  • Prior-year transactions

Archived data remains accessible for reporting and compliance, but is removed from day-to-day operational views to improve performance and usability.

Prep Systems for the New Year

Data hygiene automation also allows teams to reset or prepare systems for the upcoming year by:

  • Rolling over counters and sequences
  • Clearing temporary tables
  • Locking prior-year records
  • Rebuilding summary caches and dashboards

These processes can run automatically during off-hours, ensuring systems are ready on January 1 without manual intervention.

 

Why It Matters

Taking time to clean up your database before January can deliver both immediate and long-term benefits:

  • Faster system performance
  • More accurate reports
  • Fewer user errors
  • Cleaner analytics and forecasting
  • Reduced technical debt

Instead of starting the year by fixing old problems, teams begin with a reliable foundation.

Claris FileMaker makes year-end data hygiene efficient and repeatable through automated scripts that remove duplicates, validate records, archive outdated data, and prepare systems for the year ahead. With the right cleanup workflows in place, organizations can enter Q1 with confidence in their data and the systems that rely on it.

Interested in automating data cleanup and optimization with Claris FileMaker? Reach out here, and we’d be happy to help.

EOY Customer Analysis: Using FileMaker to Identify Top Performers, Trends, and Churn

Posted on by Frank Kobola

As the year wraps up, customer data becomes one of the most valuable assets a business can analyze. Understanding who your best customers are, where churn risk exists, and how behavior has changed year over year is critical for planning retention strategies and revenue growth in the coming year.

With Claris FileMaker, organizations can centralize customer data and use dynamic dashboards to surface insights around performance, lifetime value, churn risk, and long-term trends without exporting data to spreadsheets or external BI tools.

Identify Your Best Customers and Highest Lifetime Value

FileMaker dashboards can automatically rank customers based on metrics such as:

  • Total annual revenue
  • Purchase frequency
  • Average order value
  • Contract value or renewal history
  • Long-term lifetime value (LTV)

By consolidating sales, billing, and engagement data, FileMaker makes it easy to see which customers drive the most value and which relationships are worth expanding further in the new year.


Spot Churn Risk Before It Becomes a Problem

Churn often shows warning signs long before a customer leaves. FileMaker can analyze indicators such as:

  • Declining order frequency
  • Reduced spend compared to prior periods
  • Missed renewals or delayed payments
  • Decreased engagement or activity

Dashboards can automatically flag at-risk customers, allowing teams to prioritize outreach, retention offers, or account reviews before revenue is lost.


Analyze Year-Over-Year Customer Trends

Year-end analysis isn’t just about individual customers—it’s also about understanding broader patterns. FileMaker enables teams to track:

  • Year-over-year revenue changes by customer segment
  • Shifts in buying behavior or product mix
  • Geographic or industry-level performance trends
  • Growth or contraction across customer cohorts

These insights help leadership teams understand what changed during the year and how customer behavior is evolving.


Build Dashboards That Update in Real Time

Because FileMaker dashboards are connected directly to live data, customer analysis updates automatically as records change. Teams can create:

  • Executive-level customer performance summaries
  • Sales dashboards by territory or account owner
  • Retention and churn monitoring views
  • Account-level customer health reports

All without maintaining separate spreadsheets or manual reporting processes.


Why It Matters

End-of-year customer analysis with FileMaker helps organizations:

  • Focus retention efforts where they matter most
  • Identify upsell and expansion opportunities
  • Reduce churn risk heading into the new year
  • Base planning decisions on real data, not assumptions
  • Align sales, marketing, and customer success teams

Instead of reacting to churn after it happens, businesses can plan proactively using accurate, centralized insights.

Claris FileMaker empowers organizations to transform year-end customer data into meaningful insights. By surfacing top performers, churn risk, lifetime value, and year-over-year trends through live dashboards, FileMaker helps teams enter the new year with clarity and confidence.

Interested in building customer analytics dashboards with Claris FileMaker? Reach out to Kyo Logic here.

Schema and Table-Level Insights: Using the Admin API to Audit Your Database

Posted on by Kyo Logic

FileMaker 2025 introduces powerful new Admin API endpoints that give developers and IT teams deeper visibility into their databases than ever before. With detailed schema reporting and table-level insights now available programmatically, administrators can analyze their solutions, audit structural changes, and prepare for migrations directly through the Admin API.

Retrieve Schema Details Programmatically

In previous versions, developers relied on manual reviews or third-party utilities to inspect schema details. With FileMaker 2025, the Admin API can now return structured JSON describing elements such as:

  • Tables and fields

  • Field types and options

  • Relationships and dependencies

  • Indexing and storage attributes

  • Layout-level field references

This allows teams to pull complete schema snapshots on demand, which is ideal for version tracking, documentation, or modernization planning.

Identify Unused Fields and Legacy Structures

Once schema data is available in JSON, developers can analyze:

  • Fields that never appear on layouts

  • Deprecated tables or relationships

  • Missing indexes

  • Field-level inconsistencies across versions

  • Areas where normalization or cleanup is beneficial

This makes it far easier to reduce technical debt and optimize performance across older FileMaker systems.

Support for Migration and Refactoring Projects

Large refactor or migration projects often require understanding how data structures are used across scripts, layouts, and relationships. By using Admin API schema endpoints:

  • IT teams can map dependencies

  • Developers can automate impact analysis

  • Migrators can validate structures before exporting data

  • Organizations can create automated “schema audits” as part of deployment pipelines

This elevates FileMaker development into a more disciplined, enterprise-aligned workflow.

Why It Matters

With schema insights exposed through the Admin API, FileMaker 2025 gives teams:

  • Greater transparency into database design

  • Automated tools for health checks and documentation

  • Stronger governance over evolving systems

  • Faster modernization and easier migrations

It’s a major step forward for organizations maintaining mission-critical FileMaker applications.

Interested in auditing or modernizing your FileMaker architecture? Reach out to Kyo Logic here.

 

 

FileMaker for Year-End Compliance & Audit Readiness

Posted on by Kyo Logic

Year-end audits and compliance reviews place heavy demands on organizations, especially for those operating in regulated industries. With Claris FileMaker, businesses can automate document management, audit trails, and regulatory reporting to ensure they’re fully prepared when auditors come calling.

Centralized Document Management

FileMaker allows teams to store and organize:

  • Policies and procedures
  • Financial records
  • Compliance documentation
  • Signed approvals
  • Supporting evidence

All documents can be linked to records, dates, and responsible users, thus eliminating file sprawl and last-minute searches.

Built-In Audit Trails and Activity Logs

FileMaker can track:

  • User actions
  • Record changes
  • Approval workflows
  • Data access events

These logs provide a clear, timestamped history of system activity, which is essential for audits, investigations, and regulatory reviews.

Automated Year-End Reporting

With data already centralized, FileMaker can generate:

  • Compliance summaries
  • Audit-ready reports
  • Regulatory exports
  • Executive sign-off packages

Reports update automatically, reducing the manual effort required during year-end close.

Why It Matters

Using FileMaker for compliance and audit readiness helps organizations:

  • Reduce audit stress
  • Improve data accuracy
  • Strengthen governance
  • Maintain consistent documentation
  • Demonstrate control and accountability

Instead of scrambling at year-end, teams stay audit-ready year-round.

Claris FileMaker provides a powerful foundation for year-end compliance and audit preparation, especially for automating documentation, logging activity, and reporting with precision. For organizations facing increasing regulatory pressure, FileMaker delivers confidence and control.

Interested in strengthening your compliance workflows with Claris FileMaker? Reach out to Kyo Logic here.