FileMaker Extra: Incorporating Reports into the Workflow

FileMaker Extra: Incorporating Reports into the Workflow

The focus of this chapter has been on the creation of list and subsummary report layouts. There's a bit more to creating useful reports, however, than merely setting up nice looking layouts: You have to incorporate reports into the user workflow, controlling how a user both accesses and exits a report. The methods you choose may vary from solution to solution, and your choice is a function of both what the system does and the particular audience. If the users are proficient with FileMaker, they may be comfortable manually finding and sorting a set of records and navigating to the appropriate layout. More often, however, users benefit from your taking some time to set up some infrastructure to help them access the reports properly.

There are many ways you can go about building reports into the workflow of a solution. Following are some of the most common that we've seen over the years .

• Place buttons to run reports on relevant data entry layouts. For instance, on an Invoice Entry screen, you might have buttons for creating an Invoice Aging report, and on a Contact entry layout, there might be a Callback Report and a Contact Activity Report. Users typically are expected to find whatever data they want included in the report; the script simply goes to the correct layout, sorts, and previews.

• In your report scripts, use Custom Dialogs to give users certain choices about how the report will be generated. For instance, a dialog may prompt them whether they want to produce a report for the current month's data or the previous month's.

• You can create a centralized "Report Menu" layout that can be accessed from any place in your solution. By centralizing your reports, you can avoid having to clutter data entry layouts with report buttons. Also, you give your users one place to go any time they want a report, rather than require that they memorize which reports can be generated from where. A centralized report menu works well when the report scripts run predetermined finds.

• As a variation on the "Report Menu" concept, you can give users control over finding and sorting the data. You can, for example, place global fields on a layout so the user can enter a date range on which to search. The find criteria is usually specific to a certain report or group of reports, so you need to branch to the appropriate "finder" layout when a user makes a selection from the report menu.

• You can enable users to modify the title of a report or to add a secondary header of their own choice. This typically is done with custom dialogs, but you can also incorporate this element into a report menu or finder layout.

After the report has been generated, you'll probably want to return users to wherever they were before running the report. Try to avoid a situation where a user gets stranded on a report layout without any tools to get back to familiar territory.

You should also strive to have some consistency in how reports look and function in your system; this will make using them easier and more intuitive for your users. For instance, you might set up as a convention that reports are always (or never) previewed on screen, and then users are prompted whether they want to print a report or not. Similarly, place layout elements such as the title, page number, and report date and time in consistent locations on your reports so users don't have to hunt for them.