Phased, Deferred, Revision, TCO, and C of O record types

Revisions

Generated through workflow, separate related record – plan review only, is not a permit

• Definition – the request for a material change in the submitted plans for a project – either by the Applicant or the Agency – and occurs most commonly at application during plan review, or less commonly post-issuance at inspection. A revision requires additional plan review and approval before commencing any work included on the revised plan and often times continued work on the original plan.
• Launch a revision record from Workflow > from any Review task or the Inspection task, but are invoked most typically from a review task.
• Options for handling Revisions: Additional Info Needed/Received or Revisions Requested/Received. Primary differences are that using Revisions Requested/Received provides the detail and tracking of the review/approval process of the revised plan submittal separate from the review of the original plan submittal – Additional Info Needed/Received does not, only shows that you asked for something and they turned something in so should that 'something' need additional review, you would then have to Supervise in to workflow and reopen previously completed review tasks.
• Child Revision records have only review tasks included in the workflow.
• How to: “Revisions Requested" result on parent record – on any review or inspection task - and input specifically what you need in the Comments, a workflow email is then automatically generated in the background and sent to the Applicant indicated on the record – if no email is recorded for the Applicant, then other manual form of contact must be made with customer/applicant to notify them of this request. Customer turns in what was requested, and then “Revisions Received" result will generate the new related child Revision record.
• Creation of a Revision record will automatically post a Notice Condition on the parent and child revision records indicating a revision has been submitted, this is very helpful and informative to internal staff and anyone externally tracking the record's progress through ACA.
• Once in revision workflow – Revision Acceptance task > “Revision Accepted" result opens the Parallel Task window with all the plan review task options listed, select what is/isn't specifically required for review of the specific revised plan submittal.
• Permit and Plan Review fees for the overall permit/project only occur on the Parent Permit record, as well as all Inspections – the only fee on the Revision plan review record is “Additional Plan Review" for the time required to review the revised plan submittal. Any changes in total project valuation are also only recorded on the parent permit record. Important note: the child Revision record is only to record the plan review process of the revised plan submittal and is not a permit; additionally multiple revisions can be submitted.
• Revision record does not automatically close, has to be manually closed via workflow task which subsequently unapplies the Notice Condition.
  
  

Certificate of Occupancy (C of O)

Workflow task and report only

• Definition: formal documentation that occupancy to new construction has been granted and how the structure/space is to be qualified and used.
• Is initially generated through the Certificate of Occupancy workflow task on Structural record types.
• Important note: you can regenerate a C of O through the Reports page if there were issues/incomplete items in the one generated automatically by workflow.
• Requires that the Occupancy Type and Group in the Valuation Calculator be completed for all parts of the building whether using for fees or not, this occupancy/group data populates required fields on the C of O document.
• If regenerating a C of O from the Reports page to include additional data or a correction, best practice is to delete the prior C or O generated leaving only the 'official' C or O of record in Documents.
• The C of O only contains those elements required by Code. No 'wet' signature is required on the C of O by code exception when generated by the ePermitting program.
  
  

Temporary Certificate of Occupancy (TCO)

Generated through workflow, separate related record; only documents the approval process for TCO, is not a permit

• Definition: formal required documentation that only temporary occupancy has been granted for a specified amount of time and only for an area/portion of the structure with the indication that an additional TCO will be requested and required if more time is needed to complete the project and that the new structure/construction will be completed to Code and granted a full C of O through final inspection approval.
• Is generated from the parent record workflow – specifically from the Inspection Process task by adding a result of “Temp C of O Requested" – it is invoked in the Inspection Process because the request for TCO is generally requested during inspection on most projects
• Creation of a TCO child record will automatically post a Notice Condition on the parent record that a TCO is in place – the Notice is unapplied when the parent record Finals
• The TCO child record has its own approval-only workflow – workflow on these is not intended to be repeat of plan review but only approval of the request to temporarily occupy based on work done and inspections completed – who is required to approve is determined through Parallel Tasks
• TCO Acceptance workflow task – “Request Accepted" kicks off the approval process and opens Parallel Task for determination of who must sign off approval of the request to temporarily occupy.
• TCO Issuance workflow task – “Temp C of O Issued" result indicates summary approval of temporary occupancy and is required along with completion of several Task Specific Info fields (TSI) that populate the TCO document
• Number # of days – will take the date the TCO is generated plus the # of days indicated and will then print this date for expiration of the TCO period on the TCO document showing how long the temporary occupancy has been granted for
• TCO document is actually generated on the parent – you go to parent workflow and result the Inspection Process task as “TCO Issued" (is currently set to “TCO Requested") once the request is approved on the TCO child, doing this auto-generates the TCO document
• The TCO child record will close automatically when parent closes/finals
  
  

Deferred Plan Review

Generated by creating as a NEW record – plan review only, is not a permit

• Definition – the option of deferring portions of a building design (structural elements) and allowing it to be submitted later. Must be declared up front at intake what portions are being deferred. Not until all the deferred plan portions are submitted and approved can a permit be issued or work commenced. Does not apply to deferred permits such as the trades EMP or Fire.
  

• Examples of structural deferred review design elements include engineered trusses, engineered stairwell, elevator shaft, etc.
• Important to note the parent record ID before creating as this is required to generate the new record
• New record: Commercial or Residential > Deferred (is setup in the Model for Structural only -
  EMPs and FIRE are standalone permit records
• At SPEAR/intake: enter the value of deferred portion only (not the total project) and the “Master Application #" which is the parent record ID
• The Deferred Plan Review workflow only includes plan review tasks – is not a permit, it provides a clean way to track the plan review of the deferred submittal separate from the initial plan submittal reviewed on the parent record.
• All reviews happen through deferred record workflow; once done – record does not automatically close, must be closed manually via workflow task.
• The Deferred Plan Review record automates the Deferred Submittal Fee only – this fee is in addition to standard plan review fees (ORS 915-050) that are collected on the parent record and is a premium collected for the added plan review effort and coordination required when plans are submitted in portions/not as a complete full plan set, therefore the customer is not 'paying standard plan review fees twice on the same valuation' which is a common misconception. No permit or standard plan review fees occur on the Deferred Plan Review record. Commonly called “Deferred Permit" but is not a permit.
  
  

Phased Plan Review

Generated by creating as a NEW record (Project and Phased children) – Project parent is the actual permit and Phased children are plan review only

• Definition: a process of allowing structural construction to begin on a portion or portions of a building before the construction documents for the whole building have been submitted. Phasing must be declared at intake on for the total project – each phase submitted is subsequently reviewed and upon approval, an authorization to begin work on only that portion is provided.

• Must know ahead of time if customer intends on doing phasing because you will create a Phased Project parent record type > this record type is the official permit (Building > Commercial > Phased > Project) – each phase then is created as related child record (From the Project parent (PH record type) at SPEAR/intake [see bold comment below] OR separately from Project parent (PH) > Related Records > Clone Record > Building > Commercial > Structural > Phased) – related child records for phases only allow for/generate 'work authorizations' rather than 'permits' – only the Project parent (PH) generates the actual overall permit once all the plan reviews for each phased child are complete and 'approved'.
• On the Phased Project record SPEAR/intake:
• Job value = TOTAL project valuation for the overall project
• Project name is required since it is a phased project
• The cleanest way is to create the related child records for the phases from inside the Phased Project parent record SPEAR/intake form in the Additional Records table – so creating all records in one intake > Additional Records > New.
• Phased Project parent record (PH) is effectively an 'umbrella' – all phases, including the first, are all related child records (STR).
• Phased children include the structural plan review and phasing fees – permit fee and state surcharge are on the Phased Project parent as that's the actual permit record. Phased Plan Review is in addition to standard permit and plan review fees, a 'premium' to pay for the additional plan review time required to tie all the phases (plans) back together and assure they all fit and work as a total structure/project.
• If creating phased children through related records (vs SPEAR/intake) – you have to fill in the Submitted Job Value for that phase only:
  
• IF the fees are still status of NEW - then go to Invoice Fees > Add Fee > and add the Building Permit fee (since all the fees are calculated from the permit fee) which will kick off the fee scripting, recalculate all the fees, and then automatically delete the permit fee (as it was assessed and collected in total on the Phased Project parent).
• IF the fees are INVOICED/PAID – first void fees to credit excepting the Phased Application fee (is not based on permit fee, is flat fee), then Add Fee – add only the Structural Permit fee and other applicable fees will add automatically (Structural Plan Review, Phased Plan Review) – and the permit will then be automatically removed once the other fees calculate and add.
• Related child records for the phases:
• On related child records, result of 'Work Authorized' produces equivalent of 'permit issued' which then generates the Work Authorization report as a document
• Inspections are done on the related child records – may include final inspection or not, this is a business decision – may elect to do final inspections on Phased Project parent instead or do them on both to close the loop. The C of O is generated from the Phased Project parent.