FileMaker database and application development

New FileMaker database or system modernization

We divide a new solution into stages to test its key process with future users early. For an existing database, we start with an audit and a map of dependencies.

We work both on FileMaker itself and on the solution's surroundings: hosting, web portals, integrations and automatic document creation.

The first output is a list of user tasks, system boundaries, and a working piece of the solution to test together. We use existing modules or starter solutions when they fit the data model; scope adjustment takes place before expansion.

• multi-station applications
• mobile solutions
• panels available through the browser
• integrations and automation

Data model in front of screens

We describe business objects and relationships: a customer may have many contacts, an order may have many items, and a document may have subsequent versions. We select keys and validation rules. Thanks to this, the same information does not have to be maintained in several places.

We design layouts for roles and activities. The seller needs a different view than the person executing the order. We enforce permissions at the level of data access, not just by hiding the button.

• Customer, order and items as related records.
• Forms, lists, portals and reports for specific roles.
• Container fields for photos, signatures, scans and documents.
• Verification of required data, identifiers and allowed changes.

Scripts, imports and integrations

Automation should have a clear result. We determine the reaction to a missing record, an invalid file, an interrupted connection or a restart of the same task. We also test for incorrect cases, not just correct imports.

When migrating from Excel or CSV, we check data types, empty values, duplicates and connections. The trial import ends with a comparison of the number of records and business checksums, e.g. order values. Continuous integration additionally requires establishing a schedule or event and how corrections will be handled.

• mapping and organizing source data
• scripts and calculations with error handling
• printouts, reports and controlled exports
• API integration and adaptation of existing plugins

How we receive and communicate the solution

We refer to the acceptance criteria for specific activities: e.g. correct processing of the order, reproducing history or generating a document. A trial migration allows you to check the completeness of your data before launch.

The scope of the transfer includes agreed documentation, administrative access, change implementation procedure and user preparation. We determine further maintenance and development separately.

One database, with screens adapted to where people work

The rich office form, quick pickup on iPad, and browser dashboard use the same data model but have different interface requirements. We design the navigation, field size, keyboard, and number of steps needed to complete the task.

For browser access, we choose WebDirect or a separate web application connected via API. When offline work is needed, the design involves a local dataset and controlled synchronization, rather than just copying a file.

Audit and development of existing databases

The overview includes the relationship graph, scripts, custom functions, printouts, permissions and hosting. We look for dependencies on old versions, plugins, external files and services. We measure problematic operations before change so that improvement can be assessed.

We analyze old runtime solutions and Pro Advanced installations along with the method of distribution. Ultimately, we choose the supported Pro, Go or WWW access model. After modernization, users receive instructions for changes and the agreed scope of support.