Getting Your Banner Black Belt (Lesson One): Refuse to Become Overwhelmed



Mastering the art of Banner reporting can be easier than you might think! While Banner is a very complex Enterprise resource planning (ERP) system, the first step in understanding its inner workings is to refuse to become overwhelmed by the multitudes of data that exist within it. This blog is the first in a series that will help curb your reporting fears and point you toward some resources that can help you get ahead and earn your Banner Black Belt.

Don’t Let the Database Overwhelm You

There was a time, early on, when a simple data request would result in a ‘deer in the headlights’ look. After all, Banner has over 4,000 tables. However, this paralyzing fear can be alleviated with one simple truth: You’re never going to be pulling data from all 4,000 tables.

For any given request, you will likely only need data from a handful of tables. (And those tables are typically well organized.)

The organization is really the key factor here. For any given functional area, there are only a handful of critical tables that you’ll use over and over. Anything beyond those are usually used only on occasion.

Reference guide

To get comfortable navigating your institution’s Banner tables, keep a quick reference guide to your most commonly used tables close at hand. (This one can be very useful.) Keep in mind that the tables listed in the guide in no way reflect all the tables you may need. But if you’re doing a report in one of these areas, the chances that you’ll use one or more of the tables listed is very high. The point of the guide is to remind you, in those moments when you’re feeling overwhelmed, that while Banner may have over 4000 tables, you’ll probably only need a handful of them for any given request!

Don’t Let the Report Requesters Overwhelm You

It’s an unfortunate truth that, as technical individuals, we often tend to think that what the functional folks do is none of our concern. The initial request process can often be a frustrating interaction. We just want to know what you need, where to find it, and where to put it in the report. The requester might not have the answer to any of these questions, but with a little bit of tongue-biting and a little bit of empathy, it can be surprisingly easy to lessen that initial frustration.

Up-front communication

Oftentimes, we forget that our friends in the functional world can sometimes get overwhelmed themselves, paralyzed by not knowing what they can and can’t ask us to do. Sometimes, they themselves don’t even know what they need. Keeping this in mind, there are couple things to do when first approached with a request.

  1. When talking to a functional user about their needs, let them know up front that you can probably do anything they ask.
  2. Also, let them know that the harder (i.e. more complex/obscure) the request is, the more time and work it will take to complete that request.

Getting those two points out there, right out of the gate, accomplishes several things. For one, it reminds them that you’re all on the same team and that you’re there to help. For another, it puts them at ease, knowing that you’re happy to field any of the questions they have whirring around in their heads. And of course, establishing the fact that some reports will take longer helps manage expectations about the report generation process.

Drafting the report

After putting those points out there, then try to approach report writing from an iterative or a piece-by-piece mindset. Focus on delivering a working draft of the report as quickly as possible, with the expectation of fine-tuning it during subsequent iterations. While the report requirements process is important, getting the requester’s feedback on the first draft can also give you a better idea on what they need. It allows you to fine-tune the report to the requester’s needs without major overhauls. Keeping the requester in the loop on your workflow plans is another good way to keep their expectations in step with your own.

Don’t Let the Data Overwhelm You

Another element of Banner reporting that can be quite overwhelming is the discussion of the data itself. For example, when a report requester asks for information on FTE students, what do they really mean by that? Which definition of the term are they using? Do they know there’s more than one? Fortunately, a lot of the stress inherent in this part of the process can be avoided with simple, well-developed requirements documents…which is discussed in-depth in Part 2 of our Getting Your Banner Black Belt blog series.


Like this blog?

You might also like this On Demand webinar:

Starting out as a Software Support Analyst, he connected with our products and mission. He worked diligently to support the MAPS suite and our clients. As a Professional Services Engineer, Brian LaPlante spends his time designing functional end user experiences and implementing Evisions products. He works in our Irvine, CA campus. Brian focuses on Argos, FormFusion and MAPS, as well as our newest Products. He enjoys finding new and innovative solutions to our client’s needs.

Related Posts


1 Comment

  1. Stephen

    Thanks Brian…. This is a great blog especially for individuals just starting to daunting task of report writer. Developing a working knowledge of those common tables is a must to becoming a successful report writer. It also decreases the turnaround time for reports.

    Once again great advice!



  1. Getting Your Banner Black Belt (Lesson Three): Learn to Love SQL | Evisions - […] the first two parts of this blog series? Check out Part 1 and Part […]
  2. Getting Your Banner Black Belt (Lesson Two): Use Good Requirements Documents - Evisions - […] assure you it’s not. This article is the second in our Getting Your Banner Black Belt series. (Read part…
  3. Getting Your Banner Black Belt (Lesson Two): Use Good Requirements Documents - Evisions - […] assure you it’s not. This article is the second in our Getting Your Banner Black Belt series. (Read part…

Submit a Comment

Your email address will not be published. Required fields are marked *

Share This