Methodology to support client specific dashboards

nlarson

Most of my users are returning to me with a limitation in my app around seeing their data broken up by department. Since my tool is designed to help businesses manage their goals, seeing data broken out by department is pretty importance and I feel like I've pushed this off about as far as I can, so I have recently been giving it some thought and came up with a few ideas.

Departments are user defined by each client in a picklist. The good news is that even across industries there are a finite number of departments, with a fair bit of overlap (i.e. sales, marking, development, etc.), the bad news is that even with the common departments out of the way, there could be many unique values.

Here is what I was thinking:

Option #1:
Create a single VP which contains a number of queries arraigned as a dashboard. At run time, the user is prompted for 'please choose a department' from their list. The value is stored to a NPBO and then the queries are run using the value in the NPBO as part of the where.

Pros: only 1 VP to manage, easy to set up with no on going work.
Cons: not sure if it can be done. not super elegant.

Option #2
Create a many VP with predefined queries, only show the VP in the menu if the clients user list

Pros: cleaner interface and user experience. Menu shows all their departments.
cons: need to create a vp for every department, list could get pretty large as we grow. I do not know if hiding so many times on a menu would noticeably impact performance. There is a potential to need to so some amount of configuration for every client.

Anyone have any other options? I am biased towards option 1, if it can be done.

ACDC

I have implemented an organizational structure in my app where i have an Org that owns Companies , that owns Divisions that owns Departments

So when a user is set up they have to be assigned to the relevant organization,company,department. Every entry posted by the user into the application is stamped with this signature, or an algorithm based on the signature

Then in my rules I use PROTECT to hide data that's not relevant to the user based on which department/company/org the user belongs to.

Maybe using a similar concept and utilizing PROTECT in your rules or somewhere in your presentation matrix would help you

nlarson

Thanks Rod. I use protect rules to hide tenant data too which sounds similar to your structure. However, in this case I am looking to actually have VP Tabs or Menu options show/hide based on what data the client has defined in a table. So rather than hide data I am trying to create a semi-dynamic app layout.

I know I can do this using the visibility rules for a menu, but my concern is that if I have many unique department values (say 100 or more across say 40-50 clients) in the future the menu display performance will suffer due to all the query conditions I have packed in there. Also a secondary concern is that setting it up that way may require some custom work and an upgrade for each client.

The other method is cleaner to execute, but not as nice from a user perspective since they will need to click a menu then input data to generate the view.

Unless anyone has an alternate suggestion, I am going to do some testing to model each method later this week and see how I like them.

tford

With Option #1, you might consider using LoggedInSystemUser to store the current dept info. This allows a User to navigate among views & even log in & out and the selected dept info will persist.

A drop down of available depts could be specific to the particular client. You would not have to show all depts to all clients except when they are building their own list of valid depts.

nlarson

I think Option 1 makes the most sense. going to try it later this week. Thanks guys.

ninap

hi,

we have the same models of bsv's and solved it this way

an employee (System User) is a member of an office (BO) and customer (BO). Each get a unique id, and have a short cut ref each. example

employee.shortcut_employer (in here is the employer ID)
employee.shortcut_office (in here is the office ID)
offices.ownerid

these then serve as the primary keys to help "firewall" data in Query's

so our common queries are named My_xxxx or Our_xxxx
with filters as

LoggedInEmployees.shortcut_employer = offices.ownerid (which is the same PKEY)

i hope this helps....

also once you have built the initial Queries you can "stack them" and further use this as filters on other drop downs, table look ups etc..

(Then if your real worried about fire-walling data - you can have further checks in the UI, Menu or Forms to reconfirm)

tford

ninap,

also once you have built the initial Queries you can "stack them"

I'm curious what you mean by this.

ninap

tom,

perhaps wrong word "stacking" but what i was trying to say is

Once you have created the initial queries which firewall data for your Departments, Offices, Divisions or Territories. (like a foundation/base)

then you can re-use them in filter criteria.

i guess how i visualize it is like a base foundation of "Our Companies Data" then make general BSV queries (which are BSV wide) on top and re-use the "filters" again so to contain the data.

txs, nina 🙂