Covenant enforcement is often one of the core management services a management company provides for its client communities. The CiraNet enforcement system is designed to assist them to enforce uniformity among community owners with well-defined business rules in accordance with standardized escalation policies. Our process employs a series of template style notices to streamline fulfillment and clarify the action needed while being consistent for all owners by merging in a specific community's unique rules and regulations. CiraNet can support both fining and non-fining paths, which can be customized to suit community policy'. This Process Paper is designed to provide an introductory primer into the configuration steps to prepare the community manager and/or inspector to begin employing the process.
- Introduction to the Components
- Managing the Violation Restriction Definitions
- Split by Section
- Escalation Logic
- Definitions and Default Settings for Key Escalation Configuration Terms
- Non-Fining Path Escalation Logic
- Non-Fining Configuration Details
- Fining Path Escalation Logic
- Option One: Simple Fine Method
- Option Two: Escalating Fine Method
- Option Three: Custom Fine Method
- Fining Configuration Details
- Converting to Fining
- Violation Notices
- Modifying the Notice Templates
- Photos
- Manager Review
- Taking Action
- Appendix A Sample Notice Templates
Introduction to the Components
The configuration setup is divided into three separate steps, which are interdependent:
- Violation Restriction Definitions. This module lays in the specific restriction language into defined violation categories / sub-categories. The key components to this configuration are:
- Contract Text. The contract text taken directly from the community association's covenants, bylaws, and/or rules and regulations.
- Control Reference Number. This field identifies the governing document, article and section where the contract text is found.
- Clarification Text. This is an optional field to help define or clarify any contract text.
- Compliance Text. This text gives the recipient some basic information on what they need to do to bring the home back into compliance. There is default compliance text included in all sub-categories, but it can be overridden to include more community-specific information.
- Escalation Logic. This step sets the logic lanes the violations noted will follow through the system until the matter is either resolved or escalated to another entity (attorney, force compliance, etc.). In the Enforcement Configuration module in CiraNet, this is set using the Violation Escalation Configuration.
- Violation Notices. These are the templates set with merge fields that allow each letter to be standardized in their messaging but also includes language unique to the violation cited by laying in the language populated in the Violation Restriction Definitions.
Managing the Violation Restriction Definitions
This module lays the foundation for the community's enforcement process by providing the specific contract language, compliance requests, and any clarifications that will merge into the letter templates discussed in further detail below. This step is always configured at the community level, as it is specific to each community's governing documents. For management companies utilizing the CiraConnect Shared Services Groups services, as a community is being transitioned onto the CiraConnect platform, the CiraConnect On-Boarding Shared Services Group will assist the management team with configuring the basic information based on the governing documents and any additional rules and regulations that are received at the time, but in general, this step is manager controlled, and can be edited when needed. Violations are organized into Categories and then Sub-Categories, which are pre-set as part of the module, and can be enabled as applicable. Within the sub-category, the following construct is as follows:
- Configuration. Select Violation Restriction Definition from the drop-down menu. For many users, this will be the only option available.
- Context. Next, select the community to work on. Users can scroll through the options, or type in at least part of the name of the community to search and select.
- Search. To select the sub-category to edit, click on the arrow to the right of the main category title to open to the list of available options or use the Search at the top of the pane to find the option you need. Once you have located it, click on the title to open the editing pane to the right.
- Include. To begin laying in data for the sub-category, slide the toggle from Off to On to enable that sub-category.
- Review Required. If enabled, this option will cause every notice pertaining to this violation subcategory to be queued in the manager's WorkInBox for review / approval before being sent.
- Auto-Close Period Override. This option allows the user to override the set auto close period (see below for details) for the community in increments of full months to either longer or less time than the default setting, but only for the sub-category.
- Clarification. This field allows the user to further enhance the language taken directly from the governing documents to help the owner to better understand the oft-times purposefully vague restriction language and/or provide additional clarifications/ policies that the Boards have adopted (e.g., preapproved paint colors, or screening devices for trash receptacles, etc.). This is not a mandatory field.
- Control Reference Number. This will reference where in the documents the text listed below in the Contract Text section are from. The convention used when setting up the initial configuration on the community's behalf is to "assume" the contract text is from the Declaration of Covenants, Conditions and Restrictions (DCCR's) and therefore not to restate that title, but just reference, exactly as it is styled in the document the Article and Section the text was quoted from. If the text is taken from a different source, then we will cite the name of the document (e.g., Rules and Regulations) and then any identifying header, such as Article and Section or Section Title.
- Contract Text. This allows for a direct quote from the community association document. The onboarding team will add the text with quotations and use ellipses to clearly indicate if, and at what point, text has been omitted. CiraConnect team members will commit so stringently to maintaining a direct quote from the source documents that any typographical errors in the original source document will be retained in the Contract Text.
- Compliance Text. Each sub-category is provided default compliance text that relates to it specifically. For most communities subscribing to violation enforcement processes through the CiraConnect platform, the default text is adequate. However, it can be overridden at the subcategory level. To do so, simply slide the Override toggle, which will enable the text in the space below to be written over.
- Save. Finally, be sure to hit Save after editing each sub-category.
In each case, note that there is a character counter provided to let the user know how many characters are remaining in the maximum allotted space. Spelling is checked by your chosen browser. If a word is not recognized as correctly spelled, it will be underscored in red. The category and sub-category titles themselves by default do not merge into the letter templates (although those are available merge fields), so their primary function is to allow internal users to select the right violation information when noting a situation out in the field. Additionally, they are used to collate open violation reports in the Compliance node in CiraNet, and they are also used to collate the data in the Restriction Summary, which is one of the Information Summaries that owners and board members may avail themselves of as a summary presentation of their community's information. Additional sub-categories can be added in certain circumstances. To have an additional sub-category considered for addition, please have a supervisor open a Technical Support ticket using the Configuration option identifying the requested addition, and the language that would be used to populate it so the request can be properly evaluated. However, users can also use the <see notes> option to lay in restriction language that does not fit cleanly into available sub-categories. Please note that the compliance text will need to be manually added when using this option.
Figure 3: The Sub-Category Tree Split by Section
Split by Section
For communities where different sections may have different use restrictions, CiraNet can accommodate that by splitting the sub-categories by section. The category and subcategory titles themselves remain static.
Escalation Logic
Proceeding to the next step, the escalation logic that the violations will follow is set. The escalation logic is configured first as a standard default for the management company, but then can be massaged at the branch and then community level in accordance with its specific rules and regulations.
A community configuration is determined in part based upon whether it imposes or fines or not. If fines are allowed for in the community, then an additional consideration would be whether the community adheres to a simple or simple escalating fining path or uses a more complex fining, which would require a custom fining configuration and cannot be wholly accommodated systematically by the platform, necessitating manual processes by the management team. More on fining below.
Definitions and Default Settings for Key Escalation Configuration Terms
Some key terms to understand pertaining to the varied escalation paths are as follows:
Term | Definition | Default
Configuration |
Certified Notices | This setting determines if and under what circumstances Final / Pre-Fine and/or Post-Final / Fine Notices are sent via certified mail. Options are: Never Send, Manually selected during approval, Automated Final, Automated Final and 1s Post Final and Automated Final and all Post Final. | Never Send |
Community AutoClose Period | The period a violation record will remain open before systemically closing if no additional action is taken.
Use of this mechanism allows a manager/inspector to mark a violation as Fixed, but if it is noted again within the "probationary" period, it can be immediately escalated to the next notice in the configuration. | Six Months |
Courtesy Notice | A friendly reminder to the owner of the violation noted. | Enabled |
Final Notice | For communities that do not fine, this level produces a final warning letter, including a time to cure, and it encapsulates state-specific regulatory language. The letter templates for this level vary the language accordingly depending upon the state and other factors. | Enabled |
Fine Notice | For communities that fine, this level produces a fine letter expressly stating the amount of the fine levied. CiraNet can automate the production of this letter at this level under the simple and escalating fine methods where the fine amount is fixed and levied after each failed inspection where the violation is not cured.
If a community chooses a more complex fining method, then no letter is produced through automation.
Instead, an email is sent to the manager stating the details of the violation and includes the text which describes the community's fine policy. It is then up to the manager to produce the violation letter manually, upload and mail the letter and manually enter the fine invoice on the member's account using the Miscellaneous Invoice tool in the CiraNet application. | Available but not enabled |
Fixed | If an open violation appears to have been rectified upon a subsequent visit, it can be noted as Fixed, meaning no additional action or notices will be generated, but the violation record remains open for the time pre-determined by the Auto-Close period. If no further issues are noted during that time, the violation will systemically close at the end of the period. | |
Minimum Time Between Notices | This setting enforces the amount of time that MUST pass after a particular violation is recorded before a subsequent failure to cure can result in the next letter being sent. | Between Preview and Courtesy Notices: no minimum
Between the Courtesy and Standard Notices(s): 10 days minimum Between the Standard and Final / Pre-fine Notice: 10 days minimum
Between the Final / Pre-fine and Post-final / Fine: 30 days minimum |
Not Fixed | If an open violation remains unresolved, it should be noted as Not Fixed during the subsequent inspection and the next step in the escalation configuration will systematically be queued for processing. | |
Notice (or Standard Notice) | This level is configurable to allow up to 9 Standard Notices to be sent if the violation is marked as Not Fixed upon continuing inspections. The notices will be a repeat of the notices sent previously with the sole difference being the notice number automatically assigned in the header grid. | Enabled for a Single Notice |
Post-Final Notice (or Pre-Referral Notice) | For communities that do not fine, this escalation level produces a Post-Final letter (Pre-Referral letter). The Post-Final letter will continue to be sent as long the violation is noted as Not Fixed; however, it will not offer additional hearing requests outlined in the Level 3 (Final / Post-Final) letter.
This level allows the manager to monitor the progress of the violation and consult the board for legal action; therefore, it will be queued in the manager's WorkInBox for review and approval before sending. A manager may choose to Accept or Reject these letters on a case-bycase basis through a Workflow process. | Enabled |
Pre-Fine Notice | For community associations that fine, this notice level produces a Pre-Fine warning letter, including a time to cure and state-specific statutory language. The letter templates for this level therefore vary by state / region.
This notice is not produced for communities requiring a custom fine configuration. In those cases, the management team will need to manually produce and fulfill the notice at this step. | Available (but not Enabled) |
Preview | The violation is noted and becomes an open record, but no notice is generated and sent.
This was designed with the concept that most owners find themselves out of compliance inadvertently and will correct the situation without any prompting from the community, in which case no expense was incurred by the community nor any ill-will generated through receipt of a notice, but it is noted as having been observed so if it does recur it can be tracked as a recurring issue and notices will begin at that time. | Enabled |
Printing Provider | CiraConnect partners with a third party printing provider for system-generated notices and statements; however, there is an option to print notices at the management office plus some additional options. Discuss these options further with your leadership team if necessary to consider an alternate provider. | Optimal Outsource |
Prompt for Hearing During Violation Review | If a hearing is required as part of the compliance process, this can be checked to have the system prompt the manager during the review process to insert the appropriate information to merge into the letter template. | Available (but not Enabled) |
Send Tenant Notice | If elected, the system will generate and fulfill two notices at each step: one addressed to the owner at their mailing address and one to Current Resident at the property address. This is triggered by the Has Tenant option being checked in the owner Property Statuses. | Yes |
Time to Cure | This will merge into notice templates to provide a timeline for owners to understand the expectation for compliance before receiving any additional notices or additional action being taken. | 14 Days |
Violation ApprovalCertifieds | This option relates to the setting in the Certified Notice field and whether that choice can be overridden. | No Override Allowed |
Non-Fining Path Escalation Logic
The violation escalation configuration pathway for a non-fining community follows the flow seen on the top of the next page.
Non-Fining Configuration Details
The violation escalation configuration for a non-fining community can be illustrated as follows, with the blank columns being dependent upon community and contractual circumstances:
Fining Path Escalation Logic
As noted above, the CiraConnect platform can fully support uniform fining or uniform escalating fines as detailed below:
Option One: Simple Fine Method
This option is fully automated by the CiraNet platform. A flat rate fine is added as a set rule for that community, and once the violation escalation reaches the Fine Notice stage, a letter stating the amount of the fine is sent to the owner and the application adds the stated amount to the owner's account. If the violation remains open, the process will repeat with each subsequent Fine Notice that is sent from the application.
Option Two: Escalating Fine Method
This option is also automated and allows for up to ten (10) different individually defined fine amounts, with each amount levied by the application when a Fine Notice goes out. The community association can specify the maximum number of escalations to allow for, so long as it does not exceed ten (10). Once the maximum number of escalations is reached, there is the option to either stop fining or continue fining at the maximum escalation level. The escalation to the next fine amount occurs upon subsequent inspections where the violation has not been cured. Both the Simple and Escalating Fine Methods must follow these basic rules:
- The fines levied on the owner's accounts are in conjunction with the inspection schedule. In other words, if the inspections are done on a bi-monthly basis, the Fine Notices and the resulting fines for all open violations at that escalation stage will be applied at the time the inspection results are uploaded to CiraConnect.
- Fine amounts must apply to all violation categories equally.
Option Three: Custom Fine Method
If a community association employs a fining policy that does not meet the parameters of either options noted above, then it falls into the category of a Custom Fine. Examples of this would be:
- Daily fines;
- Varying fine amounts by violation type (e.g., a trash can left in view carries a $25.00 fine, while a violation of the architectural standards carries a higher fine);
- Varying fine timelines by violation type (e.g., a trash can left in view is assessed daily, but the architectural standards violation is based on a per inspection violation);
- Amounts are determined by a committee or the board and are not pre-set. Currently, these complexities cannot be configured into the application using systematic logic. Therefore, this option is NOT automated by the platform at this time and must be administered manually with coordination between the inspector (if applicable) and the manager. No violation letter is automatically produced past the standard notice step. Instead, an email is sent to the manager for this community stating the details of the violation and the text that describes the community's fine policy. It is then up to the management team to produce the Pre-Fine and Fine Notice letter manually using the Custom Violation Letters, which will entail printing and mailing the letter and manually entering the fine invoice on the owner's account using the Miscellaneous Invoice tool in the CiraNet application.
When a community opts for Custom Fining, the Custom Fine Method requires a detailed definition to be documented in the Escalation Configuration, which is configured by members of your company's leadership team and/or your Account Manager; therefore, they will need to be provided with details on the policy being enforced as part of the configuration set-up.
Fining Configuration Details
The violation escalation configuration for -fining community can be illustrated as follows, with the blank columns being dependent upon community, contractual, and fine policy dictates:
Fining is not without costs to you as a managing agent or your client community association in terms of increased fulfillment and administrative fees. As your service partner, CiraConnect is also impacted by the costs associated with the implementation of fines, which generally result in increased call and email volume, plus processing time. Refer to your management company's individual Service Level Agreement and your agreement with CiraConnect to understand additional fees levied in relation to the administration of fines, including mailing costs, and be prepared to discuss that with any boards wishing to implement a fining policy so they have the opportunity to elect how they want to cover those costs: as pass-throughs to the individual owner's accounts, for example, or if they are absorbing them in the fine amount assessed.
Converting to Fining
If a community adopts a fine policy where previously they did not fine, that conversion has ramifications for any open and in-process violation records; therefore, it is incumbent upon the management team to understand that in advance and advise their board and communicate with the owners appropriately prior to requesting any configuration changes. There is a separate Tip Sheet detailing this process.
Violation Notices
There are four universal templates assigned to all community associations by default, which are:
Escalation Level
Courtesy Notice
Standard Notice
Final / Pre-Fine Notice
Post-Final / Fine Notice
Each is set with merge fields to allow the unique sub-category violation and compliance language to be embedded into the letter, along with certain other fields, such as location of the violation, selected from a drop-down menu when reporting the violation and a regarding field, which is a brief clarifying remark typed in by the inspector when out in the field. Examples of standard templates are attached?. While these default templates work well for most community associations, templates can be modified at a management company, location, or community level. Letter templates can utilize either a company or a community association's logo, but do not require one if it is not available. Pre-Fine and Final notices are typically set with any state statutory language required. This is the notice level that will support merging in hearing date, time and location.
Modifying the Notice Templates
Only members of the CiraConnect Technology Shared Services Group can edit existing violation templates; therefore, once out of the on-boarding phase, if a change is requested, please work first with your location leadership and/or Account Manager who will request the change through User Support. We cannot accept change requests directly from management team members; they need to have been reviewed and approved by our leadership team first since certain changes can impact your company's Service Level Agreement. Additional costs may apply to edit letters past the initial on-boarding set-up.
If your community is considering changes to the default letter templates, there are a few things to consider:
- By default, the systematic notices have a set header that includes a header grid that lists certain key information about the notice, including the Violation Notice ID and the Notice Type. There is also a default footer in Spanish that states, "If you do not understand the reason you received this letter, please call 855-877CIRA or toll-free 855-877-2472 for a translation." We cannot edit these areas. The option is to remove them altogether.
- There is a separate Tip Sheet listing the available merge fields. Please reference it and be specific which merge fields to use and precisely where in the body of the letter they should be inserted.
- Custom Response Templates are a different process. Please refer to the separate Tip Sheet that details that process.
Photos
The Enforcement module does support the addition of photos into the letter template, but by default photos are not included. Please refer to the contracted Service Level Agreement for additional costs. If contracted to include, they often are not added until the Final / Pre-Fine notice level but can be included in all templates. Unless specified otherwise, photos will print in black and white (while they are archived in color). The notices will support up to three photos and can be specified to merge as Small (1" x 1"), Medium (2" x 2"), or Large (3" x 3").
If the community declines to use photos in violation letters, the platform can still support archiving photos as part of the violation record. They can be seen as part of the detailed violation history. They are also filed in the owner's Document Archive in a folder entitled Violation Photos and are automatically enabled to be visible to them only on their Resident Portal.
Manager Review
To support many of our valued clients who utilize a separate inspection team, notices meeting certain criteria are queued for manager approval before being fulfilled using the My WorkInBox. These criteria are displayed in the approval queue with a status flag as follows:
Pending Approval - Inspector Flagged. This flag indicates that the violation was flagged for review by one of the following two methods:
- The violation was marked as Request Review by the inspector while performing a routine violation inspection using CiraMobile.
- The violation was marked as Request Review when submitted via the Report a Violation tool in CiraNet or CiraMobile. This tool may be used by internal users or board members.
Pending Approval - Deed Restriction Definition Flagged. The violation subcategory was marked as Review Required in the Violation Restriction Definition module.
Pending Approval - Property Flagged. The specific property owner was marked as Violations Require Review in the Property Statuses for the owner.
Pending Approval - Standard. The violation has proceeded through the standard escalation process and reached Level 3, the Final / Pre-Fine Notice level or above.
If the reason for review is anything other than Standard, the violation will stay in the approval queue for 14 days before expiring. If no action is taken, the violation will be considered unapproved and will disappear from the queue. Users will see the activity in the Violation History as Inspected - No Notice Sent (Not Enough/Too Much Time Passed). By then, the violation has become "stale," and reinspection is recommended.
If the reason for review is due to a Standard escalation path, the violation will stay in the approval queue for two full business days. If no action is taken by then, then on the third business day it will auto-approve.
Taking Action
Violation records requiring review are presented to the manager in a workflow in their My WorkInBox. When the manager clicks the Action button, you will see a pop-up window with the details of the violation. Various links and tabs allow the user to research any needed history of the violation, property or owner before deciding. When ready, the user may select from the following options:
- Approve. The pending violation notice will be sent out.
- Reject. No notice will be sent out. The system will behave as if the violation citation had not happened, though the historical log of it will remain. If the violation is cited again (and approved), the escalation process will pick up from where it left off.
- Leave in Queue. This takes no action, and the violation will remain in the queue for the user to return to later. However, if too much time passes before approval is given, no notice will be sent.