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 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, and then potentially returns the user to the original layout.
- 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 users as to 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 anyplace 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 anytime they want a report, rather than requiring 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 that 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.
- A third variation on the Report Menu idea would be to literally create a Reports custom menu. A custom menu of reports could offer contextual listings of available reports from a given area of your database, or it might simply offer all the reports available within your solution.
- 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 layout dedicated to preparing records sets for reports.
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 in which 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 onscreen, and then users are prompted as to whether they want to print a report. Similarly, place layout elements such as the title, page number, and report date and time in consistent locations on your reports so that users don't have to hunt for them.