Component Reference

This page is the full inventory of what a TAP configuration request can reach. It is organised by platform area, in the order you normally build in: data model first, then interface, then workflow, then security, then reporting.

​

Data Model

​

Tracked Data Objects

Two kinds, and choosing correctly between them is the most consequential data-model decision on a TAP project. Parent and child relationships are established as one-to-many or one-to-one.

​

Data Elements

Every field on a tracked object is a data element with a declared type. Each element can be marked required or optional, and carries its own name and display label.

​

Reference Data Objects

Reference data objects (RDOs) hold the values behind Choice and Reference fields. Case Type, Priority, Status Reason, and Document Type are typical. You supply the human-readable values only. The platform manages the underlying codes and ordering. Typical requests

• “Create a Case object with fields for Case Number, Case Type, Open Date, Assigned User, and Status.”
• “Add a child object for Case Notes with note text, author, and timestamp.”
• “Link Violations as a child object of Inspections.”
• “Create a reference object for Inspection Outcome with values Pass, Fail, and Reinspection Required.”
• “Add a Case Type of Appeal to the existing reference object and make it available immediately.”

​

User Interface

​

Data Forms

Each tracked object gets one or more data forms, usually including a default form. Configurable on a form:

• Field order, and which of the two columns each field sits in
• Section headers and banners
• Embedded data listings, typically child records or related items
• Embedded charts, typically summary figures for related records

Typical requests

• “Redesign the Case form to group contact details into their own section.”
• “On the Application form, show a listing of related Payments.”

​

UI Policies

UI policies make a form react to the data in it. Conditions are built on field values such as Case Type or Status. Each policy is a single type. A rule that both reveals a field and makes it mandatory is two policies, and the agent creates both. Typical requests

• “If Case Type is Other, show and require the Other Case Type Description field.”
• “Make Closure Date required when Status is Closed.”

​

Data Listings

Listings are the queues users work from. For any tracked object you can set the columns shown, the default filters, the sort order, and therefore which records appear. Listings also embed into a parent form to show child records. Typical requests

• “Create a listing of open Cases assigned to the current user, sorted by due date.”
• “Create a listing of Payments associated with a particular Application.”

​

Charts

Charts are built from an existing data listing. Specify the chart type, the grouping field, and the aggregation such as count or sum. Charts embed on forms and in custom views. Typical requests

• “Show a bar chart of open Cases by priority on the Case dashboard.”
• “On the inspector dashboard, chart inspections completed by month.”

​

Custom Views

Custom views are dashboards, portal pages, and landing pages, laid out with containers, rows, and columns. They hold listings, charts, static content and banners, and navigation controls. Typical requests

• “Build a supervisor dashboard with three columns: my team’s open Cases, aging Cases, and a chart of Cases by type.”
• “Create a public landing page that shows basic figures and allows no editing.”

​

Workflows

A workflow is configured per tracked object and has to be turned on for that object before states exist.

​

States and Statuses

Two levels. States are the high-level lifecycle; statuses are the detail within a state.

​

Transitions

Transitions move a record from one status to another. Each belongs to a transition category such as Opening, Progress, Escalation, or Closing, and exactly one transition is marked as the initial transition, which is how records enter the workflow.

​

Transition Permissions

Transitions are restricted by system role, which is what ties the workflow to the security model. A transition from Assigned to Closed can be limited to supervisors, and that restriction is enforced by the workflow rather than by form design. Typical requests

• “Set up a workflow of New, Under Review, then Approved or Rejected.”
• “Add a Pending Client Response status and the transitions into and out of it, available to case workers only.”

​

Roles, Users, and Groups

​

Roles

A role carries permissions per tracked object: Create, Read, Update, Delete, and Search. Each permission is granted at an access scope. Case Worker, Supervisor, Read-Only Auditor, Public User, and Admin are typical shapes.

​

Users and Groups

Users are assigned a default role and any supporting roles, and can be locked or unlocked. User creation and update are available where the connected environment supports them. Groups collect users, and roles assigned to a group are conferred on its members. Groups are how regional and team structures usually get expressed. Typical requests

• “Create an Investigator role with full permissions on Case and read-only on Contacts.”
• “Ensure Clerk can only see Cases in their own organization.”
• “Create a Permits Team group and assign the Permit Processor role to it.”

​

Reports

TAP reporting uses Jasper reports. For a new report, the agent works from the fields and columns you need, the parameters and filters such as date range, status, or assigned user, and the selection logic determining which records appear. Those requirements become a report definition referencing the underlying objects and elements. Existing reports can have their fields, parameters, and filter conditions changed. Typical requests

• “Create a report of all Cases closed in the last 30 days, grouped by case type.”
• “Create a parameterised report of Inspections filtered by inspector and date range.”

​

Your Next Step