Sub-Objects

Accounts

Context: civicid

The system provides account information for all users with a civic ID.

Activities

Activities refer to past actions or past events related to a record. Activities can be assigned to a staff member when the activities require further action, such as a follow-up inspection or a phone-call.

Additional

Context: records

Provides additional details about building permit records.

Announcements

Context: announcements

Announcements are useful when agencies want to alert users about certain conditions. An announcement can be a link to a website, a simple text message, or a link to any other file, such as a PDF.

Available Dates

Context: inspections

The system compiles available inspection dates across all the inspectors. The system gets available dates and times from the inspection calendars with matching inspection type and district settings.

Document Types

Context: settings

Used by: records

The system defines specific document types that can be attached to a particular record type. For example, you can attach a graphic image, photograph, or MS Word document to a license application.

Checklists

Context: settings, inspections

A checklist contains a list of checklist items that inspectors perform to successfully complete an inspection. The checklist also provides the order in which to perform the checklist items and any other comments pertinent to completing an inspection.

A checklist contains a set of checklist items. A checklist item can include additional data from custom form data or custom table data.

Each checklist in a checklist group provides inspectors with an ordered checklist of items to go through during an inspection, and the means to indicate the status of each item. Each checklist item includes a description of the item to inspect, whether of not to allow the inspection result to pass if the checklist item fails, and so forth. A result group lists approved results that inspectors can apply to their inspection (Passed, Rejected, OK for Service, for example). The checklist group and result group provide guidelines for performing the actual inspection, resulting the inspection, and setting the inspection status.

Example Use Case

You require a foundation wall inspection, electrical inspection, and plumbing inspection before issuing a building permit. You use the Commercial inspection group that includes those three inspections for all Commercial Building record types.

Example Use Case

You set up an inspection flow process to require a new food establishment inspection every six months and you post the inspection report to public users.

When entering inspection results and completing a checklist, the inspector can choose any of the checklists in the group for the inspection type of interest.

You can carry over failed checklist items to a new checklist for the next inspection. You can also copy a checklist to a new inspection.

Checklist status groups combine sets of status values together, for inspections that must conform to specific code requirements. For example, you can use checklist status groups for building and related inspections, such as mechanical, electrical, uniform plumbing, zoning, and land use.

Checklist Items

Context: settings, inspections

A checklist contains a number of checklist items. The agency defines status values that inspectors can assign to each checklist item, determines whether a status value represents a critical score and/or non-critical score, and specifies the major violation scenarios (that is, major violation occurs with which status value for a particular checklist item).

When you complete the status for all checklist items on a checklist, the system populates the scores for all the checklist items, and for the overall checklist, in accordance with agency policy. The total score and number of major violations determine the inspection result.

Checklist Item Documents

You can attach a document to a checklist item.

Checklist Item Statuses

Context: settings

The system provides status values for assignment to each checklist item in an inspection.

Comments

Context: records

The system provides predefined comments that users can choose when they complete a form. Users can enter these frequently used comments when they update workflow tasks, enter inspection results, complete guide sheets, and add conditions.

The system associates comment groups with record types and makes all the comments in the associated group available to appropriate processes related to the record type. Comment groups consist of comment types and individual comments of a particular comment type.

Example Use Case

A user is completing an inspection form that has an assigned comment group; ?a data picker appears beside the Comments field. The user clicks this data picker to see a drop-down menu of standard comment types assigned to the inspection type. When the user clicks the hyperlink of the desired comment, the system enters the comment text in the Comments field of the inspection form.

Condition Priorities

Context: settings

Defines the priorities and priority sequence for conditions, conditions of approval, and other items. The system uses a label to indicate the priority (high, medium, and low, for example), and a numeric value to indicate the sequence of a priority (1, 2, or 3, for example).

Condition Statuses

Context: settings

The system provides various status values that can apply to a condition (required, for example). Condition statuses are useful when users know that they need to apply a condition, but they are not yet sure which severity level (lock, hold, notice, or required) applies to the condition. You can determine a severity level for the condition only when the condition reaches the “Applied” phase. Until the condition reaches this status, the condition cannot take effect to inhibit the necessary aspects of the application process.

Condition of Approval Statuses

Context: settings

The system provides agency defined status values for conditions of approval, for example pending or met.

Condition Types

Context: settings

The system provides an applied condition type and a not applied condition type, for both general conditions and conditions of approval. The ‘applied’ condition type indicates that the condition (or condition of approval) is applied to the record, record set, inspection, address, parcel, owner, licensed professional, structure, establishment, asset, or contact. The ‘not applied’ condition type removes any conditions restrictions on the record, inspection, or the component.

Example Use Case

A record has an ‘address required’ condition with the severity level of ‘hold’. When system applies the condition, the hold severity prevents the record from continuing on its workflow. After you provide the address, the system changes the condition to ‘not applied’ and the record can continue with normal processing.

Construction Types

Context: settings

The system provides standard construction types defined by the U.S. Census Bureau, for example, single family houses detached, two family buildings, industrial buildings, parking garages, and so forth.

Contact Types

Context: settings

The system provides values for three different contact types:

  • Contract types for reference, which are generic contact types such as Individual and Organization.

  • Contact type for transaction, which are role-specific contact types in daily transactions, such as Billing Contact, and Complainant.

  • Contact types for both (reference and transaction).

Example contact types include Appellant, Applicant, Business Owner, Complainant, Individual, Organization, President, Secretary, Submitter, Treasurer.

Costs

Costs are the actual spending on a work order and comprise the total work order cost.

Countries

Context: settings

The system provides standard country codes the designate the country portion of an address.

Custom Forms

Context: settings, inspections, records

During the application creation process, applications collect information for standard fields (address, parcel, owner, for example) that apply to all applications and custom fields that apply to a specific type of application (permit, plan, complaint, for example). The applicable fields depend on how your agency configured the applicable record type.

For inspections, a custom form provides a set of additional details you can require for a checklist item on a checklist for an inspection.

Some checklist items may list additional fields. For example, an item such as Roadway Conditions may include options to specify the affected roads, a drop-down list to indicate whether the roads were dry, or affected by rain, or a field where the inspector can enter additional comments. This allows the inspector to enter more detail about the inspection item.

Custom Form Metadata

Context: custom forms

The system provides drill-down list values for custom forms that present unique data choices based on previously-selected data fields. When users complete all selections, the system displays the field or a drill-down table with the value results.

The drill-down feature allows users to filter the list of value results by performing a search within the ASI drill-down result value data.

Custom Tables

Context: settings, inspections, records

The system can present application information in the form of a custom table. Custom tables accommodate multiple entries of form data, for a temporary sign permit for example.

A custom table can provide additional tabular details you require for a checklist item on a checklist for an inspection. For example, an item such as Roadway Conditions may include options to specify the affected roads, a drop-down list to indicate whether the roads were dry, or affected by rain, or a field where the inspector can enter additional comments.

Custom Table Metadata

Context: custom tables

The system provides drill-down list values for custom tables that present unique data choices based on previously-selected data fields. When users complete all selections, the system displays the field or a drill-down table with the value results.

The drill-down feature allows users to filter the list of value results by performing a search within the ASI drill-down result value data.

Example Use Case

An administrator prepares a custom table for multiple business license types. He sets the first option such as Agriculture and then assigns subgroups such as Plants and Trees Cultivation, and Seeds and Crops Cultivation. The administrator creates additional groups for each of the subgroups to narrow down the license options. After you assign the groups and subgroups, the options display in a custom table for users.

Definitions

Context: settings

The system provides information about a specified report, that includes the report name.

Departments

Context: settings

The system uses departments to identify and organize agency personnel (department members) with similar skill sets. Each agency user belongs to exactly on department. System processes that apply to a specific department apply to the individual department members.

System workflows typically assign tasks to departments. The system maximizes task throughput by distributing the tasks across department members.

The user group to which an individual user belongs, determines the user’s permission to perform a task assigned to the user’s department. Different department members may have different permission due to their membership in a different user group. If an individual department member belongs to different module user groups with different permissions, the user group permissions defined for the module from which the department action request originated, applies.

Example Use Case

Within a department, grant full access to all system functions for the agency administrator user group. Limit the desk clerk user group to specific activities, such as searching for an application.

Drill Downs

Context: settings

The drill downs object defines the values used by the custom forms and custom tables for the checklist items.

Fees

Context: settings, records

The system provides fee schedules that define and order the individual fee items, required for payment, to complete processing of a record. The record type determines the fee schedule that the system uses.

A fee schedule, combined with information on the application, determines how much an applicant pays to process their specific type of application. Each fee schedule comprises a sequenced list of fee items. A fee item represents an item or service for which the agency assesses a fee. The system supports flat fee items, point of sale fee items, and complex fee items in which fees are based on user entered data and predefined calculation logic.

Example Use Case

On an electrical application, the number of electrical outlets determines the amount of the fee. The fee per unit for 150 electrical outlets in a home differs from the fee per unit for a 20,000 square foot office building with 5000 electrical outlets. The number of outlets impacts the inspection process and the amount of time required to do it. The fee reflects the amount of work to conduct the inspection. The system can use the output value from one calculation as the input value for a subsequent calculation.

Example Use Case

A fee item determines a base fee amount. The fee item also includes an association to a calculation record. The associated fee calculation determines a separate amount and evaluates the two amounts to determine the total. The system then applies the total, from the fee calculation, to the application.

Internal agency users and public users can create partially completed applications and still get an estimate of costs payable to the agency. The system does not count partially completed applications as regular applications because they have not been fully submitted to the agency for processing. Fee estimation helps users determine the fees for a license renewal without submitting the license renewal application.

Grades

Context: settings

The system defines inspection grade groups that contain predefined grades for inspections. An inspection grade group divides inspection results into several ranges based on the inspection scores and the number of major violations. These inspection result ranges map to different inspection grades.

Histories

Context: inspections, checklists, checklist items, conditions

The system keeps a historical record (audit log) that contains details about record modifications. The history records the action performed such as added, updated, or deleted. The log also records the custom form or custom table, the field, the updated value, the date, the current user and the product.

Use Case Example

An agency user needs to determine who changed custom form data, such as the income value for a specific record, and when they changed it. The agency user accesses the record history to view changes to the custom form.
Note: The system does not record activity for partial records, incomplete applications that have not been submitted.

Inspection Statuses

Context: settings, inspections

The system provides status values you can apply to an inspection, such as Approved, Pending, or Denied.

Inspections Types

Context: settings, records

The system provides inspection types that specify the checklist group, result group, and grade group that apply to inspections of that type. One or more inspection types can belong to an inspection group.

License Boards

Context: settings

The license board is the official body responsible for granting the license for the type of professional.

Mileage

Context: inspections

Mileage is the distance travelled by an inspector's vehicle when performing a work order. A mileage entry includes the start and end odometer reading, date when the mileage was travelled, the vehicle ID, and the inspector ID.

Parts

Parts are consumable assets belonging to a parts inventory that allows an agency to track their usage and supply. The parts inventory defines each individual part, the location of the part, and the contact information about the vendor or manufacturer. Users link these parts to work orders. When users use these parts while fulfilling a work order, Automation updates the part supply and part location.

These parts are also available for use when creating part transactions and when creating work orders. When there is more than one location for a part, users can update the location and quantity on hand for the part by creating a part transaction. Users generate a part transaction each time a part is assigned to a work order, a location receives a part order, a part is transfered between locations, a part is reserved, or manual stock adjustments are made.

Parts are tracked and stored in part locations. Each part location maintains a current total supply on hand for each part. Automation uses the part supply when locating parts for work orders, re-orders, and transferring of parts from locations. When a part location is added, it is available for reference and association with specific parts within the parts inventory.

Pick Lists

Context: settings

A pick list is a drop-down list containing values for the user to choose from. A pick list is equivalent to the "shared drop-down list" in Automation.

Preferred Channels

Context: settings

The method by which the contact associated with the public user, prefers to receive notifications, for example by phone, email, fax, or postal mail.

Priorities

Context: settings

Defines the priorities and priority sequence for conditions, conditions of approval, and other items. The system uses a label to indicate the priority (high, medium, and low, for example), and a numeric value to indicate the sequence of a priority (1, 2, or 3, for example).

Profile

Context: civicid

The system maintains profile information for the user associated with the civic ID. The profile information includes login credentials, name, address, phone number, email, and so forth.

Professionals Salutations

Context: settings

The salutation to address the licensed professional associated with the record, for example doctor.

Professionals Types

Provided by: settings professionals

The system provides a list of professional license types from which you can choose to associate with a professional, for example, electrical, mechanical, and plumbing.

Races

Context: settings

The system provides a list of races from which you can choose to assign to a contact, for example, black, white, latino, asian, and so forth.

Record Types

Provided by: settings

When you create a new application, you specify the record type from which to instantiate the application record. The system provides a set of record types that define the processes the system uses, and other artifacts the system creates and manages, during the records lifecycle.

Record Type Statuses

Context: settings

The system provides status values that can apply to record instances at different stages of the record lifecycle. Record status determines the operations you can perform on a record and your permission to perform those operations. For example, when a record changes its status, the workflow can lock the record from further activity until the status changes to a status that releases the lock.

Example Use Case

The workflow limits access to a building permit record when the status changes to plan review. The workflow limits access by restricting the ability of users to schedule inspections or result inspections, the workflow only allows users to view the record. When the record status changes to issued, users can schedule the necessary inspections and result an inspection.

Relations

Context: settings

The system provides different values, from which you can choose, that define the type of relationship of a contact with an application, for example, payor, property owner, citizen.

Related Inspections

Context: inspections, records

A parent inspection can include one or more related child inspections. Child inspections typically involve follow-up inspections to the main parent inspection.

Report Categories

Context: settings

The system provides pre-defined categories of reports, for example building, enforcement, hearings, service requests, and so forth.

Report Definitions

Context: settings

The system provides information about a specified report, that includes the report name.

Salutations

Context: settings

The salutation to address the contact associated with the public user, for example Mr. or Ms.

Staff

Context: settings

Administrators maintain a list of individual agency users that belong to a department. Each agency user belongs to exactly on department. System processes that apply to a specific department apply to the individual department members.

Standard Comments

Context: settings

The system provides predefined comments that users can choose when they complete a form. Users can enter these frequently used comments when they update workflow tasks, enter inspection results, complete guide sheets, and add conditions.

To make standard comments available to a particular form, assign individual comments to a comment type, assign the comment types to a comment group, and associate the comment group with the appropriate record types.

Example Use Case

A user is completing an inspection form that has an assigned comment group; ?a data picker appears beside the Comments field. The user clicks this data picker to see a drop-down menu of standard comment types assigned to the inspection type. When the user clicks the hyperlink of the desired comment, the system enters the comment text in the Comments field of the inspection form.

Standard Comment Groups

Context: settings

The system provides predefined groups of comments for specific record types. These comment groups provide suitable comments for processes related to the associated record type. Comment groups consist of comment types and individual comments of a particular comment type.

States

Context: settings

The system provides a list of standard state acronyms to be used for addresses.

Street Directions

Context: settings

The system provides a list of standard street directions to be used, in conjunction with the street name, when you specify an address. For example, use N to indicate the north direction of a city or street, such as North Broadway.

Street Fractions

Context: settings

The system provides fractions for use in fractional street addresses, such as “1/2”. You can specify a range of factional street numbers in the corresponding Start and End fields.

Street Types

Context: settings

The system provides standard street types to use for an address. The street type provides the standard street category, for example avenue, boulevard, circle, and so forth.

Time Accounting

Context: inspections

The system can record the time spent to conduct an inspection. The system uses these items to calculate fees and levy charges for an inspection.

For general time accounting, Automation provides the ability for employees to record the amount of time spent in performing their daily tasks, the descriptions and costs of materials used while performing those tasks, and the usage of vehicles related to the tasks performed.

Automation captures time accounting information in two contexts:

  1. Time and materials

  2. Time related to a particular process or group of processes

As employees log their activity in the Time Accounting Tracker, the agency calculates fees and charges, and applies them to a record. Agencies can also record costs, for reporting purposes, not related to processing any specific information. The agency can define any number of time accounting types and assign an hourly rate or percentage adjustment to use to for each type.

Trust Accounts

Context: payments

Agency customers can deposit money into a trust account that the customer can drawn from when they need to pay fees for an application. This is helpful for customers that have a large amount of work they regularly perform in your jurisdiction, such as contractors or developers.

Automation allows you to set up trust accounts for address, parcels, licensed professionals and contacts. The trust account functionality allows you to establish and maintain trust account information, perform trust account transactions, and print trust account reports.

With the trust account feature, users can set one primary trust account and associate the trust account with one record or multiple records.

Automation can send an email notification to the trust account manager when the trust account balance drops below a certain amount. For example, if the trust account has a $100 threshold amount and the trust account falls below $50, Accela Automation sends an e-mail notification to the trust account manager.

Administrators can assign one or more trust accounts as global to one or more modules, which makes the trust accounts available to all records within the specified module. This feature allows users to access a temporary trust accounts to process refunds.

Unit Types

Context: settings

The system provides unit types that describe the structure at an address, for example, apartment or condo.

User Comments

Context: records

The system tracks comments, made by a particular user, on a specific record.