FileMaker Instant Web Publishing, Part I: Is IWP Right For You?

Posted by donovan 04/15/2011 at 11:55PM

FileMaker's Instant Web Publishing, a.k.a. "IWP", essentially converts your FileMaker layouts into basic web pages and forms. Yes, your FileMaker database could be accessible through a web browser!

This post is the first in a two-part series designed tol guide you through the process of choosing and implementing FileMaker Instant Web Publishing. Here, in Part I, I'll cover why and when to consider using IWP.  Stay tuned for Part II, which will dig deeper into IWP implementation.

FileMaker on The Web: Beyond Traditional Deployment

For workgroup database users, traditional FileMaker deployment is "client-server". In this setup, each user in a workgroup uses a FileMaker Pro client to connect to FileMaker Server, which hosts the database files. You get FileMaker's desktop interface, with the full functionality of layout objects, scripts, etc. 

However, there are situations where this traditional deployment may not be the best solution. Here are some of those cases:

  • Not every user has FileMaker Pro software (e.g. users outside your organization)
  • Users are far away (e.g. overseas), causing slow connection speeds
  • Users have limited bandwidth (again, causing slow connection speeds.)
  • Users are accessing via mobile device

Web deployment is one of the primary options for these situations because it allows you to view your database through a web browser instead of the FileMaker client.  Web browsers are great because they are now ubiquitous and can be very efficient at transferring data.

[Note, web browsers are not the only option. Some notable alternatives include terminal services, FileMaker Go, or even an "offline" client that syncs data with the server. But these are also topics for another day.]

Common Web-Based Interfaces To FileMaker

FileMaker provides several options for web deployment:

  • Static Web Pages
    • Save FileMaker records as HTML pages, then host them from the FileMaker Server web folder, or on another web server
  • Instant Web Publishing
    • Provides interaction with FileMaker Server* though static web pages and simple forms generated by FileMaker Pro
  • Custom Web Publishing
    • Serves data to dynamic web pages via XSLT (being deprecated) or PHP
    • FileMaker 11 provides a Site Assistant for both XSLT and PHP to help you generate your pages
  • Using FileMaker as an ODBC data source
  • Using FileMaker as an XML data source

You can view FileMaker's documentation on these options here.

* IWP also works from a single-user copy of FileMaker Pro. Serving your database this way really limits your use of the database, so this article will focus on Server-based solutions.

Instant Web Publishing

Instant Web Publishing is often touted as a “plug-and-go” option of database publishing. In fact, IWP can be turned on with just a few clicks. This ease of deployment is its primary strength.

But with IWP's ease comes several caveats. It doesn't give you fully interactive web pages like you may expect; we're talking about static pages and forms. Your layouts will also need considerable tweaking before you can achieve any polish and ease of use in IWP.

Be aware of the following benefits, costs, limitations and considerations before committing to an IWP deployment.


FileMaker Pro clients may not be cost-effective or responsive enough when used by users who are distributed geographically. This is especially true over long distances, and when users only need occasional access. Offering users access to your database via Instant Web Publishing allows you to reach more people without the overhead of purchasing dozens of FileMaker clients.

Instant Web Publishing also helps you speed up the user experience by limiting the amount of data that needs to be transferred between the user and your server. IWP is particularly beneficial over other web deployment options in that it gives you all this functionality at a fraction of the price of building a web front-end by scratch.


The primary cost for IWP is the development required to achieve your expected level of polish and usability. While this will likely be less than the cost of a full-scale web development project, it is not negligible. You can easily see the limitations of IWP by enabling IWP in one of your databases.** The first thing you'll notice is probably that the layouts don't look quite the same. Accomodating these limitations involves work in the following areas:

  • Heavily customized layouts (to accomodate different page renderings in IWP)
  • Rebuilding UI flow (to work around page refreshes)
  • Modified scripts (to address steps incompatible with IWP)
  • New scripts (e.g. to support status area functionality)

Instant Web Publishing via server also requires FileMaker Server Advanced (as opposed to FileMaker Server). This is not a negligible cost.

** See FileMaker's Instant Web Publishing Guide for information on how to enable IWP


Some limitations of Instant Web Publishing:

  • Performance degradation for multiple users
    • You may notice the system become less responsive with even a couple of simultaneous users.
  • Fewer UI options
  • Minimal or clunky workflows
  • Requires FileMaker Server Advanced
    • Yes, as previously noted, IWP requires FileMaker Server Advanced for server deployment; it won't run with plain-old FileMaker Server.
  • Requires Internet Information Services (IIS) to be installed when deployed on Windows


Getting a FileMaker database to appear as functional, well-polished web pages requires some effort. Web pages served through IWP do not behave like a FileMaker Pro client in many respects. FileMaker's documentation emphasizes the ease of IWP and provides some tips on implementation, but leaves the reader to infer many of the considerations.

Here are some of the challenges you will want to be familiar with before attempting the IWP option. This is not to criticize FileMaker or IWP; think of it rather as a friendly list of cautions.

  • Pages will be static
    • The entire layout will need to be redrawn pretty much any time the user clicks on something or when first entering a field on the page.
  • Fields and text objects do not look the same in IWP as in FileMaker Pro (client)
    • Drop-down menus are treated as pop-up menus (which, honestly, I think are ugly).
    • Field sizes will differ from FileMaker. They will likely need to be bigger.
    • Appearance and behavior of pages on an iOS device are especially different from the desktop browser.
  • Conditional formatting does not work
    • This will negate the handy portal row highlighting technique many of us use today.
  • Buttons cannot be placed beneath other layout objects
    • This means that those buttons you like to place on a portal row will need to be above the fields or include the fields, which can be a real pain.
  • Record commits are handled differently
    • Any data entry (even when filtering) requires the user to (whether manually or via script) enter “Edit Mode”, then explicitly commit their changes when finished. Clicking outside a field does not commit the record.
  • You may want to hide the Status Area
    • IWP produces a Status Area (much like in FileMaker Pro) at the top of the web page, which might not match your desired aesthetic.
    • Removing the Status Area requires you to script all of the functionality for the user.
  • Rendering is very limited
    • Curved shapes and angled lines do not display properly.
    • Icons will display differently. Transparency may be ignored.
    • Sizing of objects is not 100% faithful to FileMaker layouts, primarily because of additional weight given to the borders of enterable fields.
    • You'll get best results with very minimalistic layouts.
  • Some scripts steps are not compatible with IWP
    • When IWP comes across an incompatible script step, it simply halts the script, unless Allow User Abort is set to OFF.
    • Notable incompatible script steps include anything adjusting windows or exporting data: Freeze Window, Show Custom Dialog, Print, Enter Preview Mode, etc.
  • Single-window interfaces only
    • New windows will appear to replace the current page.
  • Users need to log out
    • User sessions will persist unless they press “Log Out” or a script runs the Exit Application step.
    • This is an example of a Status Area feature that needs to be scripted if the Status Area is hidden.
    • You may want to devise a process or button that ensures users log out successfully.

Below are some screenshots that compare the FileMaker and IWP renderings of a simple FileMaker layout. You will see some of the following considerations listed above in play: object transparency loss, rounded FileMaker objects become square, text looks different, conditional formatting lost, etc. Click on the image to see full-sized version.

Layout rendered in FileMaker (click to expand image)

Layout rendered in FileMaker

Layout rendered in Safari via IWP (click to expand image)

This is in Edit Mode, which occurs when the user clicks to edit the record.  I've added some comments to highlight the differences.

Layout rendered in IWP with comments


That's quite a list, but don’t let Instant Web Publishing scare you. It can still be a quick and cost-effective option when the use case is basic data entry or browsing simple lists of records. The layouts in FileMaker's starter solutions, for example, manage to render quite well in IWP. With some work you can support more complex database functionality, or at least account for how the IWP interface will affect how users interact with your FileMaker database.   

Part II of this series will give you some useful tips to ensure you start your next IWP project on the right foot.


Leave a comment

  1. Gravatar
    Pablo Ruiz about 1 year later:

    @Donovan: Do you know of a way to have users create their own accounts and passwords? I’d imagine I’d assign a default privilege set to be set for those accounts beforehand

  2. Gravatar
    Donovan about 1 year later:

    @Pabo It’s possible to script the creation of accounts. Those script steps also show as IWP compatible in Script Editor, though I haven’t tested it. You’re right about the found sets though; there’s no way to dynamically create or select those. So you’ll need to take their selection and map it to some If statements in your script that each has a separate Add Account step in it that uses an existing privilege set.

  3. Gravatar
    Donovan about 1 year later:

    @Pablo Sorry about that… I meant privilege sets, not found sets. And I got the “l” in your name this time. Think I’ll go grab some coffee!

Leave a comment