Today we are going to give you a high-level overview of some of the tools available to you while configuring Application Types in Infor Public Sector (IPS) / Hansen 8. We will be following this up with some posts specific to Assets and Billing, but this article will be focused on Community Development and Regulations (CDR), which includes Building, Use, License, and several other modules.
Defining Application Types (AP Types)
Infor Public Sector (IPS) / Hansen can be customized in a large number of ways, and this article is aimed at introducing you to most (if not all) of them. As a result, it would be possible for you to configure a single Application Type Workflow to handle all of the application processes in your organization, although we don’t recommend this. There is a larger upfront investment of time and effort to configure separate workflows for each of your application processes, but maintenance costs for a single monster AP Type will far exceed the additional upfront investment in separate workflows, and the separate workflows will produce a superior user experience. That said, there are times when it can make sense to combine your application processes into a single Application Type, differentiated by one of IPS / Hansen’s other available inputs – Work Type.
Read more about defining Infor Public Sector / Hansen Application (AP) Types
Constraints
Infor Public Sector (IPS) / Hansen includes a number of built-in questions to help you get started configuring your Application Type. One of them has already been mentioned – Work Type. Many other questions are available and they differ depending upon the Module you are currently configuring. All of the Constraints are probably not necessary for your permit application, and at the same time they probably don’t cover all of the information you need to collect. The good news is you can configure each of them to be hidden, read-only, or fully editable, and if you need to add more questions, read on to the next section…
Detail Pages and Grids
Detail Pages and Grids are custom user input forms that can be added to your AP Type to gather additional information necessary for your application process. You can add as many Detail Pages and Grids to your application as you need, and within CDR they can be added to Applications, Inspections, and Reviews. (Outside of CDR, they can be added to other entities such as Assets).
Detail Pages
An application process can have one or more types of Detail Pages that are displayed as part of the application process. Each Detail Page Type exists once per application (one-to-one). These are useful for asking additional questions that only require one answer (ex: “How many doors are you going to install?”)
Grids
Grids allow you to add multiple records to a single application (one-to-many). This is useful when you want the applicant to provide a list of something (ex: “List each door, its dimensions, manufacturer, and fire rating”). Note that Grids must exist within the context of a Detail Page (they are not directly related to the Application object) and that it is possible to have a Detail Page with no questions that only exists to host one or more Grids.
Read more about creating Detail Pages and Grids in Infor Public Sector / Hansen
Code Definitions
Infor Public Sector / Hansen provides a simple way to add any number of Code Definitions (also commonly known as “List of Values,” “LOV’s,” or “Look-Up Values”). Code Definitions have many uses such as populating dropdowns on input forms, defining result codes such as Inspection Results, or defining Status Codes such as Application Statuses. The Code Definition Manager provides the UI to define these values, which typically consists of the Code, Description, Effective Date and Expire Date, although as we will cover later in this article, these can be expanded to contain more data in addition to the standard fields.
Applicants
Applicants are any people or entities (such as a business) involved in a project. Infor Public Sector / Hansen provides a lot of flexibility in the way applicants are handled.
Core Applicants vs. Detail Page / Grid Questions
There have been some debates on this topic, but believe it or not, sometimes it makes sense to avoid using Applicants when listing all of the people that are involved in a project. At least one Applicant should always be present (the system requires it and for good reason), but when you are adding some additional information and not capturing a ton of detail about a person (ex: emergency contact name and phone number), you might be better off just adding these questions to a Detail Page or Grid rather than adding incomplete records to your Contact data.
Applicant Capacities
Each Applicant can be added to an application in IPS / Hansen with the same or different “Capacities,” which define the roles of each of these people / entities as they relate to the project.
How do I determine which Capacities I need?
In many cases municipal codes will determine the requirements for Applicants. In a lot of cases a single “Applicant” will suffice. In other cases where licensed professionals are required, Applicant Capacities can get much more granular.
As a simple example, a New Construction permit might have Capacities of General Contractor, Owner, Architect, Developer, Electrician, etc., although the structure of these Capacities depends on many factors. You could also get away with a simplified approach where you just have Capacities of Contractors and Owners, and in this case other variables might be used to determine their specific roles (related Trade Licenses for example).
Locations
Infor Public Sector / Hansen allows you to create permits against Addresses (points or ranges), Parcels, Assets, and Properties (Properties themselves are a configurable data structure that can be used to define many things). This obviously provides for a lot of flexibility, and this is another decision that must be made while configuring your AP Type.
In addition to this primary entity the permit is created against, it is also possible to add additional “Associated Sites” to a permit if your permit includes multiple locations.
How do I determine which type of entity to permit against?
Parcels
It is common to permit against Parcels when an Address does not exist, such as in the case of a brand new development of buildings involving multiple new structures. Eventually Addresses will be known, however they are not available during the initial planning stages.
Addresses
One of the more common entities to permit against because of their wide use, Addresses can be used for most CDR modules, and they can represent buildings, plots of land, or even the public right of way (streets, sidewalks, etc.).
Properties
As mentioned, Properties are a flexible data structure that can be used to define just about any logical grouping of land / buildings that you can imagine. Custom Property Types can be defined, and relationships between properties, or properties and addresses, can be defined as well. They can encompass a Campus, Complex, or an individual building or group of buildings.
Assets
Assets are another flexible data structure that can be used to represent an entity in or around a building, such as elevators, storage tanks, boiler, manufacturing / plant equipment, and fleets.
Reviews
Some permit applications can proceed through to issuance without any manual intervention by the organization – the applicant enters their data, makes a payment, and prints a permit. Other applications may require reviews by organizational staff. Reviews are another flexible entity in IPS / Hansen – any number of Review Types can be defined in the system, and permissions and auto-assignments can be based on Review Type.
Read more about Review Types and Review Results in Infor Public Sector / Hansen
Inspections
As with Reviews, any number of Inspection Types can be defined, and Inspections can be added conditionally at any point in the workflow, or depending on the type of application they may not be added at all. Inspections can also be defined as periodic where they recur every so often, such as in the case of an Annual Building, Elevator, or Boiler Inspection. While adding Inspections to your workflow, don’t forget to consider Re-Inspections, and whether you should support manually adding Inspections on the fly.
Fees
Application Fees are obviously an important element of the application process, and depending on the organization’s rules and ordinances they also be highly complicated to configure and calculate. Infor Public Sector / Hansen 8 will allow you to define any number of Fee Types that can be calculated as either a flat fee, a flat fee based on a quantity, or a completely custom formula-driven amount that can handle the most complex of calculations, and they can be added to an application at any point in its workflow.
We have seen some unorthodox fee calculation formulas that may have been agreed upon years, decades, or even generations ago. Some of these can involve a combination of numerous variables, escalating schedules, tiered multipliers, and other complexities. While it is possible for IPS to calculate any fee, these types of fee calculations can be challenging to implement, modify, and maintain, and they can ultimately cost more in support costs than the complicated structure gains. In these scenarios, it might be worthwhile to ask if the fee structure could be simplified in order to save your organization time and money.
Logs
IPS / Hansen Logs are fully configurable and they can be used in many ways. You can add them programmatically during certain events in an auditing capacity. You can allow users to add them manually to track additional information. You can use them to trigger events on an application, and they can be used for many other purposes.
Aside from standard Application Logs, there are also Application Status Logs which are system generated and exist to track the application’s progress through its milestones. Unlike Application Logs, these are controlled by the system. While they cannot be manually added, it is possible to execute event-based formula logic on these Logs, which can be useful if you want to send an email to an applicant letting them know their permit is now in the “Fee Payment” milestone for example.
How do we determine which Log Types to define?
Log Type definitions can vary as widely as Application Log usage can vary. Here are some examples of the things we typically take into consideration:
Usage
Will this Log Type be used by staff to record notes about a call they just had with an applicant? Maybe it will be used when someone on your staff wants to send a message to the applicant and some custom logic will convert it to an email that is sent to the applicants. Maybe it will be a simple audit log that lets you know some key data was changed on the application or a fee was recalculated. Maybe you want to know the number of times an applicant logged into your web portal and checked on the status of their application. All of these scenarios could represent different Log Types.
Reporting
Aside from the usage scenarios above (which could also make for good reporting), you might have some specific reporting / analytics requirements that different Log Types can help keep straight.
Events
Logs can provide another way for users to trigger events within the system; impromptu events that can kick off workflow processes or make data modifications. One such example could be a specific Log Type that allows a reviewer to go back and modify data that may have been validated and locked since a specific event occurred. Rather than opening your system up to general modifications by reviewers at any time, you are able to control specific modifications and track that they took place.
Permissions
Access to specific Log Types can be restricted to users or user groups, so if you have a specific comment or action that only certain users should be able to create it might make sense to create a separate Log Type.
Attachments
There are many scenarios where an application process might require applicants to provide documentation, pictures, drawings, etc. as a part of their application process. IPS / Hansen allows you to add any number of attachments to your application and those attachments can exist in one or more Attachment Catalogs. Catalogs can essentially be thought of as Attachment Types. There are two ways you can view attachments in the system – you can view the contents of an entire Catalog, or you can view them on the Attachments tab of the entity they are attached to (Use application, Building application, Service Request, etc.).
How do we determine which Attachment Catalogs to define?
We have seen attachment catalogs defined in a number of ways – per AP type, per Hansen / IPS module, per the document type they represent, or even one system-wide catalog. While a per-document-type approach is more cumbersome to configure, we prefer this method because, aside from providing the best organization, it also allows you to write rules that enforce certain documents being attached at specific milestones.
For example, if you have a business rule that requires the applicant provide proof of additional insurance coverage if their project reaches a specific threshold, you can write a rule within the software that alerts the applicant at the appropriate milestone that this condition must be met, basing the logic on whether an attachment from a specific Attachment Catalog has been added to the application.
Another use for an Attachment Catalog might involve generating a PDF copy of the permit at issuance and attaching it to the application. Some organizations will execute a report in real time after issuance to display a copy of the permit, but with this strategy you run the risk of data changing and misrepresenting the values that were supposed to be displayed on the permit when it was issued. By capturing the snapshot of the permit and its values at issuance you have an accurate legal document that can be referenced in the future.
Milestones
Your Infor Public Sector / Hansen workflow will consist of multiple milestones or stages. No milestones are defined out of the box, so this represents the ultimate in flexibility. As a very simple example you might have an “Intake” milestone for data entry and an “Issued” milestone that represents an issued permit. Municipal codes and business rules vary quite a bit between organizations, so it would be challenging to represent a complete list of possible milestones, however the following is a list of some of the more common milestones that we have used or seen:
Intake
Intake represents the data entry milestone where the necessary information is gathered from the applicant(s) and entered into the system, either through a web portal, system-to-system interface, or manual entry through the IPS / Hansen system.
Reviews
After all of the data has been collected in the system, there should be enough information to determine if any reviews are necessary. You might need to review structural drawings, blueprints, zoning restrictions, or possible conflicts with other permits in the area.
Payment
The timing of a Payment milestone (or milestones) varies from organization to organization, or AP Type to AP Type. Some prefer an upfront application fee, where the Payment milestone immediately follows an Intake milestone, so they are recovering the costs involved in their processing and reviewing efforts. Others prefer to wait until the end of the process and charge permit fees after all information has been gathered and the true cost is known. Of course a combination of the two is also possible, so you might have multiple Payment milestones in your workflow.
Inspections
Inspections are another milestone that can appear once or multiple times, and at different points in the workflow. Consider a new construction project that involves a foundation, building structure, electrical, plumbing, gas, etc. There is likely to be several inspections at different points in time during this project.
Issuance
As the name suggests, a permit application enters this milestone when it is issued. At this point fees have typically been paid, reviews approved, and the permit is available to be printed (if a paper permit is a requirement).
Periodic Inspection
Sometimes permitted work results in annual or other durations of periodic inspections. This can be managed within the same AP Type as the originating permit application, or it can be managed in a separate AP Type / workflow with a relationship to the originating permit application.
Cancelled
Fairly obvious, this milestone represents cancelled applications. An application could be cancelled for numerous reasons – applicant changes their mind, extended period of inactivity on the application, etc.
Closed
After an application has run its course it is good practice to “Close” the application so it is clear that there is nothing left to do on this project.
Custom Workflow Logic
In this section we’ll discuss some of your options for adding custom logic to your application process. Custom logic can cover a wide spectrum of functionality. Some simple examples include custom form validations and automated data population. Back in the days of Hansen 7 a lot of your logic may have lived in PL/SQL triggers and procedures. In Infor Public Sector / Hansen 8, custom logic is supported out of the box in many places, such as:
Business Object Events
Every entity in IPS / Hansen 8 is represented as a Business Object, both Core (out of the box) objects such as Address, Asset, Application, UseApplication, UseInspection, etc., and any custom entities / objects that you create to customize the system (think Detail Pages and Grids but the sky is the limit). Each of these objects carries a standard set of events that will be familiar to a lot of technologists – BeforeAdd, BeforeUpdate, AfterAdd, AfterUpdate, etc. Formulas can be written that execute when any of these events happen.
Conditions
Unlike Business Object Events, which can execute at any time, Conditions are a tool that is tied to an application’s workflow. Their intended use is to check that certain “conditions” have been met before allowing the application to progress to the next milestone. They act as a sort of checklist and are typically cleared manually after verifying the condition has been met. While this is their intended use, it is possible to execute custom application logic in a Condition formula that does any number of things.
Status Checks
Status Checks are similar to Conditions but they are not manually cleared. Status Checks can be considered a validation formula in a way, confirming everything within the application is as it should be. Unlike using a Business Object Event as validation, a Status Check would allow the incorrect information to be saved into the system, then it alerts the user of the incorrect information and prevents the application from progressing to the next milestone.
Milestone Formulas
Milestones can be configured to automatically move from one milestone to the next when all Conditions and Status Checks have been met, however there is also an option to write a formula that controls which milestone comes next. This can be useful if your next milestone depends on some variable or combination of variables. Aside from making a decision on which milestone comes next, additional logic can be added to these formulas to perform other actions, such as sending emails, creating Logs, etc.
Core Business Object Methods
In the previous section we talked about Custom Workflow Logic within IPS / Hansen 8. You should know that all of IPS’s Core Business Objects can be loaded and used within any custom formulas that you write, so the entire universe of Infor Public Sector / Hansen 8 Business Objects is available to you on any event, providing you with complete flexibility in how your system functions.
Aside from the basic methods such as Update, IPS / Hansen’s Business Objects possess custom methods that can be called to perform specific functions and make overall development easier by entrusting standard business logic to the Core Components that manage it. This means you don’t have to write all of the logic to apply a payment to a Use Application, for example. You can instead call a method to apply the payment and let IPS take care of the rest.
Custom Objects
The Detail Pages and Grids section talks about the ability to create custom forms and business objects when additional information is needed from an applicant on an application. Aside from these very specific uses, other custom objects can be created and used in a number of ways. Some of our favorite uses for custom objects are the following:
Extension Objects
It’s not possible to add properties / columns to the IPS / Hansen 8 Core Business Objects / Tables (technically speaking you’d have to recompile the entire Infor Public Sector application, which is obviously not feasible, and this would also negate any chance of you being able to upgrade the software as new versions are released).
So what if you have an additional property that you absolutely must have on that Core Business Object? Create a custom Extension Object (ex: AddressExtension or UseInspectionExtension), link it to the Core Business Object you wish to extend, and add your desired property/properties to it. Then you just need to write a very simple AfterAdd formula on the Core Business Object (ex: Address or UseInspection) that creates the related Extension Object record every time the corresponding Core record is created so you know it will always be present. Now you have the property available to use in formulas, reports, etc., and you can even add it to your Core Hansen / IPS UI forms (more on that in a moment).
Extending Code Definitions
As mentioned earlier, IPS / Hansen comes with a great utility for creating Code Definitions. Aside from defining the Code, Description, and effective date range for each value, it is possible to add properties / columns to each Code Definition Type that you define. This is extremely useful for configurations and mappings that you wish to store in the system, and you can use Code Definition Manager to manage these values through the IPS UI, rather than storing the values in a database table or configuration file, which can more challenging for administrative users to access.
As an example, let’s say your organization has a standard set of Budget Codes that are used for accounting purposes, and your IPS / Hansen 8 system interfaces with another system that is responsible for generating fees / receivables that can be paid within IPS / Hansen 8. There may be a one-to-one mapping between IPS’s Fee Types and the interfacing system’s Receivable Types, or there may be a many-to-one. Either way, you can create a Code Definition with the standard Code column representing the interfacing system’s Receivable Type values, and an additional column for its corresponding Fee Type within the IPS / Hansen 8 system. Now you can easily manage these mappings through Code Definition Manager without any code modifications or elaborate UI customizations.
Content Manager for Core UI Modifications
We have already talked about creating custom UI forms in IPS / Hansen 8 for Detail Pages and Grids, but those are just the beginning when it comes to modifying the IPS UI. Core application forms can also be modified in a number of ways. You can add labels, inputs, hyperlinks, buttons, etc. – anything that is available to you through the UI designer. The options are nearly endless, but here are some examples of uses that can help improve usability and add functionality to the system:
Adding a Navigation Link
Let’s say you have a Use or Building Application against an Address, and it is often necessary to browse the Building’s data as a part of a review process. You could have the building defined as a Property Type and it would be linked indirectly to the Application through the associated Address. Out of the box, navigating to the Building to view its details would require a number of clicks. As an alternative, you can add a custom link to the Use Application’s main UI form, possibly next to the Address, that consists of the building’s name or common identifier, and that opens the Building directly.
Displaying an Address on an Asset Application
As mentioned previously, permit applications can be created against several entities in IPS / Hansen 8. If you create a permit against an asset, the address where the asset is located might not be immediately apparent while you are looking at the permit application. You can solve this by customizing the main application form – simply add a label that displays the Asset’s address.
Adding Additional Job Description Values
Yes, you can customize the Job Description form as well. As an example – IPS / Hansen 8 comes with a lot of date fields, but in some circumstances, you might need one that isn’t defined in the core product. Rather than repurposing an existing date field (bad practice) you can add a new date to an Extension Object (see the Custom Objects section for more information on Extension Objects) and add it to your core UI where desired, like on the Job Description tab.
Summary
The purpose of this article was to provide you with a brief introduction to configuring CDR Modules such as Use, Building, Case, and Licenses in Infor Public Sector (IPS) (known previously as Hansen 8), and to highlight some of the many ways IPS can be customized to support even the most challenging business processes and problems. Out of the box, the product offers many forms of readily configurable features that will satisfy most requirements. Taking configuration to the next level offers ways to improve usability, streamline processes, and support processes that may be too cumbersome when using the standard methods of configuration.
We strongly urge a simplified approach to solving business problems to prevent overly complex configurations and customizations, but if you do have a complex process that must be supported, there is no doubt that IPS is up for the challenge. As always, 606 Digital is here to help and we look forward to hearing from you.
