Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

The following are the typical integration requirements for the 3rd party applications.(NOTE: PARTNER = External/3rd party Back office or iPaaS implementer systems)


INTAKE

  1. Customer portal and/or 3rd permitting application send plan review documents to Partner applications for validation.
  2. Partner application calls the e-PlanSoft Scout API to validate each plan review document.
  3. Plan Review documents that do not pass Scout will not be accepted by EPR.


PROJECTS

  1. Partner application creates the new project in EPR. This includes the project info, project address and project team members.
    1. If the contact record does not exist, Partner application creates the contact record.
    2. Partner application associate the contact record to the project record as the primary contact.
  2. Partner application updates the project information/address/contact when it is modified in the permitting application.


DOCUMENTS

  1. Partner application calls the EPR API to upload plan review documents in PDF format. Partner is responsible for document versioning (1st submittal, 2nd resubmittal, etc.).
  2. Supporting attachments are also uploaded to EPR but are not inspected by Scout.


ASSIGNMENTS

  1. Partner application calls the EPR API to create plan review assignments for the newly uploaded plan review documents.
  2. Partner application calls the EPR API to update an existing EPR assignment record (due date, status, user reassignment etc.) as necessary.


PLAN REVIEW

  1. EPR calls the Partner application API to report a change in the plan review assignment status.
  2. EPR calls the Partner application API to when all plan review assignments are complete.


DOCUMENT CHECK IN

  1. EPR users will create a compressed ZIP file from all the documents to return to Partner application (reviewed plans, attachments/correction reports, etc.)
  2. EPR will call the Partner application ‘check in’ API to provide a URL to retrieve the ZIP file from the EPR server.


PROJECT TEAM MEMBERSHIPS

EPR requires that each project consist of one or more project team members (reviewers, dept managers, permit techs, etc.) and EPR provides the ability to configure project team templates based on project types.  These templates auto insert ‘users’ into a newly saved project record. These templates will be configured and managed in EPR unless the permitting application has similar functionality, in which case, Partner may call the EPR API to the create project team when a new project is created in EPR and the EPR ‘templates’ are not necessary. 


DOCUMENT RE-SUBMITTAL

If any of plan review documents need corrections, repeat the process starting at INTAKE.


HANDLING ASSIGNMENTS FOR RE-SUBMITTAL

EPR will automatically reset the its existing assignment record statuses to ‘not started’ and point the latest document version to the assignment records. Therefore, Partner should not create EPR assignments for the next submittal. However, if the permitting application itself creates new assignment records for the new ‘submittal’, then Partner should change the EPR assignment record vendor_id to point to the new PK in the permitting application. Partner may create new assignment records in EPR for the latest submittal if an assignment was not created for the prior submittal.


CLOSING THE PROJECT

  1. Partner updates the EPR project status with the final status.
  2. Cycle Ends


EPR NAVIGATION via API calls

  1. Partner should call the EPR API to get a login token for the current permitting application user (passing the user’s email address) to:
    1. Navigate to the EPR Dashboard.
    2. Navigate to the EPR Project page for a specified project.
    3. Navigate to the EPR Assignments page for the user.
    4. Navigate to the EPR Plan Review page for a specified assignment/task.




  • No labels