Power User Guide - quandis/qbo3-Documentation GitHub Wiki

Power users are business analysts trained to use QBO to implement business requirements. The skill set for a power user should roughly be comparable to an "Excel power user". If you are comfortable using advanced Excel formulas (e.g. vlookup), pivot tables and such, you should be able to transfer those mental models to QBO fairly readily. That said, the range of skills required for a power user can vary widely:

  • Document experts should know Word, merge fields, and data well
  • Workflow experts really should know their business domain exceptionally well,
  • Scoring experts should be Excel gurus
  • Matrix experts should be good at if/then logic games
  • Query experts must know SQL
  • Plugin developers should know C#, XML, SOAP
  • Custom UI developers should know XSLT, SQL, JSON, and AJAX

To dive into QBO, we recommend gaining an understanding of the method signatures which underlie everything in QBO, including getting data into and out of the system, workflows, and more. It's always best to start with simple configuration exercises like user management, tasks and documents. As your comfort level increases, consider diving into all of the QBO components:

  • User Management
    • Add, activate and deactivate users, reset passwords and add users to teams (Labels)
    • Add users to Roles and grant access to Organizations to leverage extranet security access.
    • Add a Role and grant functional and template-based permissions
  • Import Routines
    • Build a basic Excel-based Import to get data into the system
  • Attachment Templates
    • Create an Attachment Template and assemble a Word Mail Merge transform or use a data enabled PDF (Adobe Acrobat PRO required; see video below).
    • Configure a document classification model.

Document Classification

  • Ledger Templates
    • Create a Ledger Template that applies to a parent object, i.e. Loan and add Ledger Template Items to the Ledger Template.
  • Message Templates
    • Generate a canned Message with a Subject and a Body, with fields merged into the Body.
  • Schedules
    • Create a Schedule to be used in a Workflow Polling Step or Report configuration
  • Process Templates
    • Add a Process Template that applies to an area of your business
    • Add Custom Types and Statuses
  • Workflow
    • Orchestrate the business process using a Workflow, employing at least one of each Step Type
    • Add a Hold Template, with a specified estimated duration

Create a Workflow

  • Task Templates
    • Add Questions to one of the Tasks created when assembling the Workflow
    • Add a standalone task and configure Status-based Routing

Task Creation

Status Routing

  • Rules Matrix
    • Build a Worklist Assignment Matrix
    • Build a Workflow Matrix from the Process Template Summary page

Rule configuration

  • Manage user's work
    • Configure Smart Worklists that were auto-generated by the creation of Task Templates
    • Setup Task Auditing through the Smart Worklists

Worklist management

  • Reports
    • Add a basic Report-based Statement query
    • Assemble a Report using the Statement added previously
    • Convert Report to return an Excel Spreadsheet
  • Orchestration: queuing
  • New functionality: filters, dimensions, and plugins

Testing and troubleshooting

Testing the UI

When developing complicated pages (such as Valuation Summary), it can be annoying to wait for the entire page to load or conditions to be met simply to render the AJAX panel you are working on.

You can unit test AJAX panels using:

Theme.ashx/Wrap?ClassName={Table}&Method={Method}&{Other Parameters}

For example, assume that on the Valuation Summary panel, you have the following panel:

<div 
  data-behavior="ObjectBind" 
  data-objectbind-options="{{ 
    'class': 'qbo3.ImportFormObject', 
    'method': 'RenderEdit', 
    'data': {{'ID': {//ImportFormID} }} 
  }}">.</div>

You can test this from:

Theme.ashx/Wrap?ClassName=ImportForm&Method=RenderEdit&ImportFormID=302

All the Wrap method does is mimic the div tag above.

This allows you to unit test specific statements and XSLTs without the need to go through the machinations we make users go through for data control. This is not good for regression testing, since it skips other controls you may choose to implement in Summary XSLTs.

⚠️ **GitHub.com Fallback** ⚠️