Finances - Ledgers and Dashboard - UX Iteration 1



I have some comments from Jeff Kosokoff, Head of Collection Strategy & Development at Duke University Libraries that seem best suited to this post (though it was in response to an earlier post on Funds):

"What I need to be able to do is sub-allocate different funds (endowed and UA) to one or more individual allocations that are distinguished by:

  • Who is responsible (i.e., selector)
  • What format the funds are intended for (i.e., 6661, 6663, etc.)
  • What discipline group they are a part of (ideally, this is a hierarchical relationship). In the example shown, it isn’t clear to me that this classification is available, but it is important to me that funds live inside of a classification. This is for monitoring and reporting….

One thing I liked in OLE as I understood it was the way that the format sub-allocations lived inside of subjects, which themselves lived inside discipline groups. Is that replicated in FOLIO?"

I think when you have hundreds of budgets that you are allocating to, the Tag system for reporting on and monitoring Funds via a Dashboard may not be sufficient as it can’t handle the level of complexity and hierarchy we’re looking for. Not that we have a Dashboard in Aleph - we have to export all of our data and create pivot tables - but the way we’ve structured our Fund codes and the metadata associated with allows us to do that.

I think what we’re really looking for is ways that we can roll-up the financial data in different ways - either by the individual responsible, subject area groups, ongoing vs. one-time, etc. Ideally we wouldn’t have to export all of our data to Excel in order to do so, but if the Dashboard can’t support it, we at least need that info encoded.


Another good topic for discussion, Virginia. Dennis can confirm, but the way that the fund structure is being built, it should allow for as much hierarchy/nesting or flatness that a library may need, depending on how you want to configure your money spend.

And tags are another way that FOLIO will have tremendous flexibility. It would be interesting to better understand scenarios where tags may not be flexible enough or appropriate. You’ll be able to impose as much structure or openness as wanted on the tags in FOLIO, plus you’ll be able to tag not only funds, but also individual orders and payments. All of that will be accessible in the Reporting app, so you should be able to slice and dice your money, transactions, orders, bibs, and other types of data in as many different ways as you like. Tags allow us to take the Innovative Code1-Code4 and Alma Reporting Codes and put them on turbo. So long as information is only being used for slicing and dicing, and not for triggering other actions, I think that tags could accommodate. If something needs to trigger an additional action (notify a patron, output a voucher, activate an eResource), then that would definitely need to be in a discrete, defined field.


I think there will be a lot of different tags. Is there a way to have an overview of the tags I am using or which I created? Especially when requesting a report including a certain tag it would be useful and it would be helpful to see the name structure of tags for adding new tags for example. Especially when there will be cross-apps tags. Which functionality will be available around tagging? But this is an overall question for tagging in FOLIO in general.

How can I add or select which tags will be shown as buttons in the finance dashboard?


Great point, we plan to have a “tag management” area/screen where you can consolidate tags and delete unused tags etc. However, this is very much in the initial stages of planning for a FOLIO wide solution.

The Finance dashboard will show all tags associated with the Funds appearing in the fund box at the bottom. Remember, only funds associated with the ledger(s) you’ve selected will appear in the fund box at the bottom. If you then select a tag it will filter the list of funds in the fund box as well as the list of visible tags. I hope that clarifies this functionality a little bit more.