Reports > Report Development > Keys to Successful netFORUM Report Development

Keys to Successful netFORUM Report Development

The Abila netFORUM product provides a world-class platform to capture and track your day-to-day enterprise data. While the product enables capturing your data in a wide variety of formats and modes, its Reporting Module provides an equally impressive array of options through which you can review and analyze the data that is the heart of your enterprise. Abila has gone through great lengths to anticipate general and specific reporting needs of our clients and hence bundled our product with a multitude of baseline reports that are vertically oriented with every major functional module. Despite that, we leave the door open to be able to create new or tailor an existing report to specific needs of our clients. This article summarizes the key steps involved with creating such reports.

Do you really need a custom report?

As netFORUM provides a multitude of reports pertaining to each module, it is advisable to review the baseline reports bundled in the product before you embark on creating a custom report. If you are unfamiliar with navigating to the reporting module, or need some hand holding during the process, you should consider engaging your designated project manager who will be able to guide you through the review process. Once it's determined that your report requirements are unique enough that it will warrant a new report, proceed with the following.

Clone or Custom?

At this point, you have two options:

You are able to find a baseline report that almost meets your requirements but it needs to be further extended to your specific requirements (for example aesthetic/layout changes or data extensions). If this is the case, then we can expedite your report development by cloning that baseline report and extending it.
You are unable to find any reports that match your specific requirements. Hence, you would have to request a completely new custom report written for you from ground up.

It's important to make the determination whether you will be cloning an existing report or developing a custom report as it will help set the expectations of timeframe, resources and the development cost. Whatever is the case, at this point you should start engaging with your project manager to discuss your high level reporting requirements. The project manager will work with you and guide you through the next steps. Other members of the Abila Professional Services team may also start engaging with you.

Gather Report Specifications

The most critical part in a successful delivery of a custom report is gathering of the report requirements. In order to meet your expectations during this process, we require detailed report specifications. The Report Specification form, that has been designed specifically to facilitate capturing and documenting these requirements will need to be filled out. The report specification form can be downloaded here. The following highlights some key sections of the report specification form that warrant special attention:

Report Title: Why is this important? Remember that the title of the report will be displayed in your netFORUM system and thus you want the words to depict what the report accomplishes for your users.
Legacy Format Information: We ask that you provide a sample of the legacy report which this report request is replacing. If you do not have one, a "mock-up" of what you want the report to look like is very helpful. If you have a legacy report and you want some formatting differences or want to inform Abila that they have permission to format differently/better, this is the place to let us know.
Special Output Information: This section is used to communicate any special output information regarding the report. Examples can include paper size, membership card size, envelope size, a specific Avery Label Template, pre-printed stock and if so what are the sizes so the programmer can place the fields correctly in the report, etc.
Filters (Parameters): Filters (or parameters) are criteria that define what a field(s) should be matched to and pulled for this report. Filters should be defined as required or not required. Reports can be set up to force users to enter filter values each time the report is run or is not required and users have the option of running the report without defining the filters. To the end user, filters can be visually represented as text boxes, drop-down lists, date fields, check boxes, etc. On the report specification form, Filters (parameters) are broken out into two sections; "Embedded" and "Ask at Runtime."
Embedded Filters: Generally, these are the filters that ALWAYS apply for this report. An example would be for a membership or registration roster do not pull deleted records, or for an outstanding balance due report that the balance due is greater than zero (0).
"Ask at Runtime" Filters: Generally, these are the filters that whether mandatory or not, will appear when the report is run. The user will fill out appropriately depending on the population they want from the report. You should think about and provide that if a user leaves a non-mandatory filter (parameter) blank, what should be pulled. An example is if there is a filter (parameter) for member type and the user does not choose any, should the report pull all member types, or none? It may seem obvious to pull all member types, but communicating this is vital to the programmers who may be seeing your report requirement for the first time and may not know your business.
Report Detail Fields: This is where you will provide all the fields and field headers (if different) you want on the report. In many cases you will just know the general field description such as "Name", "Address" or "Designation", however should that name include the first, middle and last name only or should the address include address line 1, 2 and 3? Should it include any designations or suffixes at the end? If you have fields specific to your organization and you know where that field will be converted in netFORUM, please let us know. In addition if you are having custom fields created for your system and it is one of the fields you want on the report, please let us know. Even if you don't know what the specific field name will be, if we know it is a custom field, we can track it down internally. Rule of thumb is, the more detail you can provide, the better.
Report Location: Here you will determine where you would like to run the report from within netFORUM. You have several options, most common being the report central under a specific module. Other options are running a report from a specific profile like a customer invoice from an individual profile or running a report from the List results. If you have a graphical report, you can also consider it running from a Dashboard page.

Depending on your preference and comfort level, you may fill this form or provide the high level information to the Project Manager and she will assist in completing this form. Once the form is completed and approved by the client, the Reporting Services developer will start working on this report.

Acceptance

After the report has been developed based on the specifications provided, it will go through some basic QA testing by the report developer, reporting analyst and the PM. After passing the internal QA, the report will be available on the test site and will be accessible to you for further QA and testing. You are strongly encouraged to think about and apply 5-7 of your own test scenarios as a part of your acceptance criteria. Upon final approval, the report will be made available on your production site.