User Applications on the Proliance Platform

User Applications on the Proliance Platform (Mike Shelnutt, Meridian)

Discussion of four things that they have recently implemented/customized. (Speaker mentioned that title isn't quite appropriate)

1) Custom User Interfaces
2) Custom Limits of Authority
3) Custom Single Sign-On
4) Password Policies

1) Custom User Interfaces
Discussed two solutions provided if you want to limit/control the user experience based on user (security) role, document state, other data conditions were discussed.

A) Excel OBA (Office Business Application).
Meridian created an OBA where a Vendor gets a familiar Excel interface to enter an RFI. The Excel file highlights fields that they can enter/are required and grays out fields that they don't have rights to. When submitting, workflow is triggered. When the PM opens up the OBA on their machine, the highlighted and disabled fields are ones appropriate to the PM, not the Vendor. The system would notify the user when the system was in maintenance mode or if they did not have the latest version of the OBA. These are the particular requirements that one client wanted (Disney?). You can create/customize how you see fit…
- Can be written by Meridian, 3rd party consultant, yourself (Meridian/consultant needs to teach you their code interfaces)
- You create a form layout, mapping database fields to Excel cells.
- Any logic/code is written in VB (our development language at WESTON).
- User installs the OBA app on their machine.
- When they open the file, the are presented with a login screen so that rules/security can be applied, but they never see Proliance.
- Create an app for each document type where you have this need.

B) Entirely new UI
Meridian developed a customized UI for the GSA called ePM where it basically sounds like they wrote an entirely new/customized UI to work with the existing Proliance backend database. Excel OBAs were written as well. Someone from the GSA pointed out that one of the reasons that this was done was because the GSA isn't standardized on using Outlook?? (Thinking about this now that I’m writing this, I'm not sure how this makes sense.)

2) Custom Limits of Authority
One client had very precise authority/approval workflow they wanted to enforce that varied by company region, dollar value, and other information; the criteria/thresholds vary annually. In Proliance 4.0, user-defined work flow states can be created. They created one to be the engine that handled this logic. When the document was in this state, the "Message Bus Adapter" was triggered (not a standard part of Proliance) while applied the logic. They stored the criteria/threshold values as Catalog Card documents so that the client could change the values each year without having to go back to Proliance to change the code.

3) Custom Single Sign-On
They had a client that created a separate application to supplement Proliance. They didn't want to have the users enter their login information into the supporting application if they had logged in to Proliance already. (They considered Proliance to be the "source of truth" for logins). This has been integrated in to Proliance 4.0. This doesn't really apply to us.

4) New Password Policies
They talked about the new password policy features recently released. Nothing earth shattering (lock out users, password expiration, password requirements, etc.). It basically brings things up to speed with what you would expect. While we use Proliance as a hosted solution, this is helpful. Should we have Proliance running on our own servers in the future, if we choose to have Windows Integrated Security enabled, Proliance trusts whatever policies we setup for folks on our network today (as well as naturally providing single sign on).