This article describes how data is integrated between nFORM and nCORE for the purposes of both (1) prepopulation of new submissions and (2) population of nCORE data elements from new nFORM submissions (round-tripping).

Data Integration from nFORM into nCORE

Integration tags are defined in the following database views:

• nFORMExport.VW_SITE_EXPORT - Imports data from nFORM into nCORE SITE details.

• nFORMExport.VW_SUBM_EXPORT - Imports data from nFORM into nCORE SUBM details (applications, complaints, etc.).

• nFORMExport.VW_FEATR_EXPORT - Imports data from nFORM into nCORE FEATR details.

• nFORMExport.VW_CONTCT_EXPORT - Imports data from nFORM into nCORE CONTCT details.

Document attachments are always imported from an nFORM submission and attached to the Submission record in nCORE. If a description has been provided for the document within the nFORM attachment control, the description will be carried forward into nCORE.

Site Integration into nCORE (including Person and Organization)

nFORM control tag mapping from nFORM to nCORE is defined in nFORMExport.VW_SITE_EXPORT. Integration logic is defined in dbo.SP_nFORM_STG_TO_SUBM_SITE.Data provided in an nFORM submission is extracted and used to update data in nCORE. Data integration rules and behavior is largely driven by the Tag value assigned to nFORM Sections and Controls. This section describes how to use tags to control data integration behavior when a new submission is received.

Submission data is used to update Site, Contact, Submission, and Feature details. Specifics for each are described in the following sections.

Site Data Integration into nCORE (including Person and Organization)

Site Control Tag to nCORE Site Database Field Mapping

The table below indicates form control Tag are used to

Submission Data Integration into nCORE

Section Tag Value = PRMT

A section tagged PRMT should only be included on Permit Change forms or Compliance Schedule forms. Since Permit Change forms (e.g., modifications, renewals) and Compliance Schedules (e.g., annual reports, notifications) are typically used in the context of an existing, in-effect permit, including a PRMT section on these forms provides a convenient way of automatically displaying information about that permit on the form. For example, the permit number and issue date can be displayed at the beginning of the form so that the applicant can confirm that they are filling out the form for the correct permit.

A maximum of one permit can be specified on a form using these tags. The PRMT section should never be marked repeatable. Information about other permits can be collected on the form but the controls for these permits should be given tag values that are not in the reserved list below.

Permit Change forms and Compliance Schedules can also contain site information, but this should be done by using a section tagged SITE containing the appropriate SITE tagged controls.

Tag Name

Data Type

Length

Description

Submission Import Behavior

PRMT_ID

bigint

n/a

Internal Permit unique identifier. Not user editable

If specified, indicates the permit (and site) to which the submission will be related

PRMT_NUM

nvarchar

50

Permit Number

NOT SUPPORTED

PRMT_VERSN

int

n/a

Permit Version

NOT SUPPORTED

REF_PRMT_CATG_DESCR

nvarchar

255

Permit Category

NOT SUPPORTED

REF_PRMT_TYPE_DESCR

nvarchar

255

Permit Type

NOT SUPPORTED

REF_PRMT_STAT_DESCR

nvarchar

255

Permit Status

NOT SUPPORTED

ISSUE_DATE

text

10

Permit Issue Date. Read-only. Only available for prepopulation.
Not imported from a submission into nVIRO

NOT SUPPORTED

EFCTV_DATE

text

10

Permit Effective Date. Read-only. Only available for prepopulation.
Not imported from a submission into nVIRO

NOT SUPPORTED

EXPR_DATE

text

10

Permit Expiration Date. Read-only. Only available for prepopulation.
Not imported from a submission into nVIRO

NOT SUPPORTED

APP_DUE_DATE

text

10

Next application due date. Read-only. Only available for prepopulation.
Not imported from a submission into nVIRO

NOT SUPPORTED

PERMT (contact control)

n/a

n/a

Permittee

Yes. The contact will be created with affiliation type “Permittee” on the submission record,

SITE (contact control)

n/a

n/a

Site Address contact control

SITE_CNTY

nvarchar

510

Site County

SITE_ADDR_CMNTS

nvarchar

4096

Site Address Comments

TAX_PARCEL_NUM

nvarchar

n/a

Tax Parcel Number

PROJ_NAME

nvarchar

510

Project name

Submission Integration into nCORE

nFORM control tag mapping is defined in nFORMExport.VW_SUBM_EXPORT. Integration logic is defined in dbo.SP_nFORM_STG_TO_SUBM.

Only one SUBM record is ever associated with a given nFORM submission.

Control Tag

nCORE Target Field

Description

CMPLNT_DESCR

SUBM.CMPLNT_DESCR

Complaint Description

IS_CONF_REQSTD

SUBM.IS_CONF_REQSTD

nFORM submission value must be YES or NO

CMPLNT_ISSUE_DATE

SUBM.CMPLNT_DATE

Joined with CMPLNT_ISSUE_TIME, if present

CMPLNT_ISSUE_TIME

SUBM.CMPLNT_DATE

Only used if CMPLNT_ISSUE_DATE tag is also present

PROJ_NAME

SUBM.PROJ_NAME

Project Name

ACTN_TYPE

SUBM.REF_APP_REQST_ACTN_TYPE_CODE

This value is mapped to the Description column from REF_APP_REQST_ACTN_TYPE.

If not supplied, import will fall back to Form's Action/Deadline setting for mapped nFORM Reason Type.

SUBM_CMNTS

SUBM.SUBM_CMNTS

Submission Comments

SUBM_DCSN

SUBM_VERSN.REF_DSCN_CODE

Specific to schedule submissions. If a matching value is found in the REF_DCSN lookup table, the submission version's Decision will automatically be set to the value supplied. 

SUBM_DCSN_DATE

SUBM_VERSN.DCSN_DATE

Specific to schedule submissions. Sets the Decision Date of the submission version to the value provided. Only populated if a valid SUBM_DSCN is found. If a SUBM_DCSN is specified but a SUBM_DSCN_DATE is not specified, the decision will default to the submission version received date/time.

RESUBM_DUE_DATE

SUBM_VERSN.RESUBM_DUE_DATE

Specific to schedule submissions. Sets the Resubmission Due Date of the submission version to the value provided. Only applicable to decision codes NOT_APPROVED and REQ_RESUBM.

Feature Integration into nCORE

nFORM control tag mapping is defined in nFORMExport.VW_FEATR_EXPORT. Integration logic is defined in dbo.SP_nFORM_STG_TO_SUBM_FEATR.

Feature information is gathered from nFORM sections whose control tags are prefixed with the text SITE or FEATR, or contains a Location control. For example, if a control in a section is tagged `FEATR_CARWASH`, the import process will attempt to insert or update a feature. There are no requirements around section tag names for data import; it is based entirely on the section's control data.

The integration logic can only create or update one feature record per section. 

Sections can be repeating to import multiple features.

Inserting versus Updating Features

nCORE will only create new features if a Feature Type is specified in the submission data. The Feature Type can be specified using any of the following methods:

1. Include a Location control whose label matches an existing Feature Type Description, or

2. Include a Location control whose tag matches an existing Feature Type Code, or

3. Include a pre-populated, hidden text control whose default value matches a Feature Type Code or Description, or

4. Include a single select control whose dropdown values match an existing Feature Type Description.

If an existing Feature is found with a matching FEATR_ID_TXT, the feature will be updated with all fields. If a feature is not found with a matching FEATR_ID_TXT, a new feature will be created upon import.

Control Tagging Rules

Control Tag

nCORE Target Field

Description

FEATR_ID_TXT

FEATR.FEATR_ID_TXT

Feature Identifier business key (e.g. "001")

FEATR_TYPE

FEATR.REF_FEATR_TYPE_CODE

nFORM value can match on either CODE or DESCR in REF_FEATR_TYPE.

FEATR_DESCR

FEATR.DESCR

Feature Description

FEATR_LOC

FEATR_LOC.(lat/long value)

Derived as a point (single lat/long coordinate) from the nFORM location control.

Tag value does not matter. Integration logic will fetch the coordinate from any location control.

Contact Integration into nCORE

nFORM control tag mapping is defined in nFORMExport.VW_CONTCT_EXPORT. Integration logic is defined in dbo.SP_nFORM_STG_TO_SUBM_CONTCT_AFFIL.

Contacts are usually created from nFORM Contact Controls.

The Affiliation Type assigned to the contact upon import is determined when either

1. The Label value on the nFORM contact control matches a Description from REF_AFFIL TYPE, or 

2. The nFORM contact control's Tag matches a Code from REF_AFFIL_TYPE

   1. If multiple contact controls in the same section need to map to a single affiliation type, use the "+" sign to add text at the end of the tag to retain uniqueness. For example, a contact control with tag CMPLNT+TEST1 will yield a contact with affiliation type CMPLNT.

A single contact can be assigned multiple affiliations by adding a separate single or multi-select nFORM control with the tag AFFIL in the same section as the contact control.

When the Applicant is also the Site, the contact control may be used to create both (Contact control Label "Applicant" and Contact control Tag = "SITE").  Note: The Site Name comes from contact Company Name / Organization field. Do not use first name/last name.  

Control Tag

nCORE Target Field

Description

Type

AFFIL.REF_AFFIL_TYPE_CODE

After contacts are added to CONTCT, affiliations are inserted into the AFFIL table linking each contact record with 1..many affiliation types matching the REF_AFFIL_TYPE_CODE.

Title

CONTCT.TITLE

prefixNames

CONTCT.PREFIX

formula

CONTCT.CONTCT_NAME

Complex formula using either the company name or a concatenation of first and last names.

firstName

CONTCT.FIRST_NAME

lastName

CONTCT.LAST_NAME

companyName

CONTCT.ORG_NAME

email

CONTCT.EMAIL

phone

PHONE.PHONE

Saves the tag mapped to "phone" as the REF_PHONE_TYPE_CODE = "OFFICE" phone. Appears to be for legacy form use only.

Uses FN_FORMAT_PHONE to format the phone number.

phone_0..3

PHONE.PHONE

Saves phone_0, phone_1... phone_3 to distinct phone records of different phoneType.

Uses FN_FORMAT_PHONE to format the phone number.

phoneType_0..3

PHONE.REF_PHONE_TYPE_CODE

Saves the phoneType of phone_0, phone_1... phone_3 to distinct phone records of different phoneTypes.

• WHEN phoneType = "BUSINESS" THEN "OFFICE"

• WHEN phoneType = "MAIN" THEN "OTHER"

• ELSE phoneType END

extension_0..3

PHONE.PHONE_EXT

Saves the extension of phone_0, phone_1... phone_3 to distinct phone records of different phoneTypes.

extension

PHONE.PHONE_EXT

Saves the tag mapped to "extension" as the REF_PHONE_TYPE_CODE = "OFFICE" phone. Appears to be for legacy form use only.

fax

PHONE.PHONE

Saves with REF_PHONE_TYPE_CODE = "FAX".

street

CONTCT.ADDR_1

street2

CONTCT.ADDR_2

locality

CONTCT.CITY

areaCode

CONTCT.REF_STATE_CODE

countryCode

CONTCT.REF_CNTRY_CODE

postalCode

CONTCT.ZIP_CODE

county

unmapped

description

CONTCT.ADDR_CMNTS

Site Alternate Name Contact Creation

Submission contacts can also be created from a control referencing an nFORM lookup populated from nCORE Site Alternate Name Types. In order for the contact to be created:

1. The nFORM control must reference an nFORM lookup where the lookup name matches a valid Site Alternate Name Type Code.

   1. See the following page for more info on populating an nFORM lookup from Site Alternate Names: Populating nFORM Lookups from nCORE.

2. The control must map to a valid nCORE Affiliation Type via one of the following:

   1. The Label value on the nFORM contact control matches a Description from REF_AFFIL TYPE, or 

   2. The nFORM contact control's Tag matches a Code from REF_AFFIL_TYPE.

      1. If multiple contact controls in the same section need to map to a single affiliation type, use the "+" sign to add text at the end of the tag to retain uniqueness. For example, a contact control with tag CMPLNT+TEST1 will yield a contact with affiliation type CMPLNT.

   3. If the tag fragment COPY is included in the tag (e.g. CMPLNT+COPY), all Site-level contacts from the selected site will also be copied to the submission.

Control Tag

nCORE Target Field

Description

Type

AFFIL.REF_AFFIL_TYPE_CODE

After contacts are added to CONTCT, affiliations are inserted into the AFFIL table linking each contact record with 1..many affiliation types matching the REF_AFFIL_TYPE_CODE.

SITE.TITLE

CONTCT.TITLE

SITE.PREFIX

CONTCT.PREFIX

SITE.SITE_NAME

CONTCT.CONTCT_NAME

SITE.FIRST_NAME

CONTCT.FIRST_NAME

SITE.LAST_NAME

CONTCT.LAST_NAME

SITE.ORG_NAME

CONTCT.ORG_NAME

SITE.EMAIL

CONTCT.EMAIL

SITE.PHONE.PHONE

PHONE.PHONE

Copies Phone from site where IS_PRIMRY= 1

SITE.PHONE.REF_PHONE_TYPE_CODE

PHONE.REF_PHONE_TYPE_CODE

Copies Phone from site where IS_PRIMRY= 1

SITE.PHONE.PHONE_EXT

PHONE.PHONE_EXT

Copies Phone from site where IS_PRIMRY= 1

CONTCT.ADDR_1

CONTCT.ADDR_1

CONTCT.ADDR_1

CONTCT.ADDR_2

CONTCT.CITY

CONTCT.CITY

CONTCT.REF_STATE_CODE

CONTCT.REF_STATE_CODE

CONTCT.REF_CNTRY_CODE

CONTCT.REF_CNTRY_CODE

CONTCT.ZIP_CODE

CONTCT.ZIP_CODE

SITE_ALT_NAME_TYPE.DESCR + ': ' + SITE_ALT_NAME.SITE_NAME

CONTCT.ADDR_CMNTS

Copies referenced Site Alternative Name to the Contact Comments.

Creating Site Relationships via nForm Configuration

Scenario: For example, selecting a contractor for an Asbestos application. When an Asbestos Notification is submitted, it needs to specify the contractor, which should be selectable from a list of current contractors (and these are configured as Person records). Once submitted and created, the Contractor Person (Site) should be related to the Asbestos Site Record.

1. When creating site relationships, the first step is to configure an nFORM form to be populated from a Site Alternative Name Lookup as per Populating nFORM Lookups from nCORE.

2. When an nFORM field, configured to use a Site Alternative Name lookup, is tagged with a valid site relationship type code, (e.g. DEMOSITE followed by a '>' sign), the chosen site in the dropdown will be created as a Related Site when the application is imported, with the chosen site as the parent, and the submission’s site as the child.

3. When the field configured to use Site Alternative Name Lookup is tagged with a valid Site Relationship Type Code followed by a “<“ sign, (e.g. DEMOSITE<) the chosen site will be created as a Related Site when application is imported with the chosen site as the child and the submission’s site as the parent.

Site Alternate Name Contact and Related Site creation

It may be desired that a selected site from a site alternative name dropdown be created as both a contact and a related site. This can be achieved by separating the Affiliation Type and the Site Relationship Type by a Plus sign: CMPLNT+ABCAFO>.

When field is tagged with affiliation type e.g. APBCT – Annual Permit Billing Contact, followed by a Plus Sign (+) followed by Site Relationship type e.g. DEMOSITE contact is created from the linked Site along a Related Site.

1. For this, create a contact control that is tagged with an "affiliation type code" + "site type code" with a > sign at the end.

   1. APBCT+DEMOSITE> on a contact control, upon import of that form:

      1. A new site/contact added as Annual Permit Billing contact (APBCT)

      2. A new 'person' (site) added and the relationship to the person/site set as 'Asbestos Demolition Contractor' (DEMOSITE)

Integration from nCORE into nFORM (prepopulation)

Prepopulation from nCORE into nFORM is accomplished through nFormImport.SOURCE_[SUFFIX] views where the view name suffix indicates the section tag to populate.

Prerequisite 

To prepopulate forms, Pre-fill → Import from External Source (SQL) must be checked:

Image Removed

For each Section that will require prefill, the Enable Form Pre-Fill (via Context ID) field must be checked and the Section Tag should be set to view name suffix of the source name eg. (SITE, PRMT, or FEATR, )

Image Removed

Available sources are: 

• nCORE - nFORM Integration Tags#Sites

• nCORE - nFORM Integration Tags#Submissions

• nCORE - nFORM Integration Tags#Permits

• nCORE - nFORM Integration Tags#Features

• Other sources can exist depends on clients needs. 

Site Prefill into nFORM

Populated from view: nFormImport.SOURCE_SITE

Available standard data for pre-population in a section tagged SITE are:

Tag

Name

Control Type

Notes

SITE_NUM

Site Number

Text Control

SITE_NAME

Site Name

Text Control

SITE

Site Location

Location Control

This will populate a location control with site coordinates

SITE_ADDR

Site Address

Contact Control

This will populate contact control or Address control tagged SITE_ADDR

SITE_CNTY

Site County

Text Control

SITE_ADDR_CMNTS

Site Address Comments

Paragraph Control

TAX_PARCEL_NUM

Tax Parcel Number

Text Control

REF_OWNRSH_TYPE_DESCR

Ownership Type

Text Control

SITE_LUG_NAME

Site Lug Name

Text Control

SITE_WATERBODY_NAME

Site Waterbody Name

Text Control

SITE_SIC

Site SIC Codes

Text Control

Any control that supports binding to dynamic datasource. Set up the control to use the SIC_CODES datasource.

The binding assumes dbo.REF_SIC.CODE = nform.LOOKUP_VALUE.NAME

SITE_NAICS

Site NAICS Codes

Text Control

Any control that supports binding to dynamic datasource. Set up the control to use the NAICS_CODES datasource.

The binding assumes dbo.REF_NAICS.CODE = nform.LOOKUP_VALUE.NAME

SITE

Contact

Contact Control

For modifying PERSON records, the Contact control can be used.

Submission prefill into nFORM

Populated from view: nFormImport.SOURCE_SUBM

This view is primarily used for:

• Populating data about the submission's parent Schedule

• Populating the Alternate Identity in the Submission Header

• Schedule Due Date (that should typically be set to Read Only when populated)

• Schedule Name (see Notes below on what it contains)

Available standard data for pre-population in a section tagged SUBM are:

Tag

Name

Control Type

Notes

SUBM_REF_NUM

Submission Number

Text Control

SCHD_DUE_DATE

Schedule Due Date

Date Control

SCHD_NAME

Schedule Name

Text Control

If there is a Custom name then that takes the priority over Schedule type name.

Populating the Alternate Identity with the nCORE-generated submission number

The nCORE source view nFormImport.SOURCE_SUBM can be used to populate the nCORE-generated submission number into the nFORM Alternate Identity, making this available on the Submission Wizard Header and Submission Summary screen:

1. Create a new section (or use an existing section), and tag it SUBM, and enable it for prefill

2. Create a new short-text control tagged SUBM_REF_NUM and make it "Read Only"

3. At the form version level in the "Details" Section, check box "Activate Display of Alternate Submission Identifier"

4. Check newly-displayed box "Override Display Label", and enter label of your choice 

Permit prefill into nFORM

Only one SUBM record is ever associated with a given nFORM submission.

nFORM Control Tag to nCORE Submission Database Field Mapping

The following table provides a mapping from individual fields on the nFORM contact control to nCORE Submission fields.

Feature Data Integration into nCORE

Feature information is gathered from nFORM sections whose control tags are prefixed with the text SITE or FEATR, or contains a Location control. For example, if a control in a section is tagged `FEATR_CARWASH`, the import process will attempt to insert or update a feature. There are no requirements around section tag names for data import; it is based entirely on the section's control data.

The integration logic can only create or update one feature record per section. 

Sections can be repeating to import multiple features.

Inserting versus Updating Features

nCORE will only create new features if a Feature Type is specified in the submission data. The Feature Type can be specified using any of the following methods:

1. Include a Location control whose label matches an existing Feature Type Description, or

2. Include a Location control whose tag matches an existing Feature Type Code, or

3. Include a pre-populated, hidden text control whose default value matches a Feature Type Code or Description, or

4. Include a single select control whose dropdown values match an existing Feature Type Description.

If an existing Feature is found with a matching FEATR_ID_TXT, the feature will be updated with all fields. If a feature is not found with a matching FEATR_ID_TXT, a new feature will be created upon import.

nFORM Control Tag to nCORE Feature Database Field Mapping

The following table provides a mapping from individual fields on the nFORM contact control to nCORE Feature fields.

Contact Data Integration into nCORE

Submission contacts in nCORE are created from nFORM Contact controls.

Configurating a Contact’s Affiliation Type

Every contact imported from an nFORM submission into nCORE is assigned one or more Affiliation Types. The Affiliation Type assigned to the contact upon import is determined as follows:

1. The nFORM contact control’s Label matches an Affiliation Type Description (e.g. “Applicant”), or 

2. The nFORM contact control's Tag matches an Affiliation Type Code (e.g. “APPLCNT”)

If no matching Affiliation Type Code or Description is found for the contact, nCORE will assign the generic Affiliation Type “Contact” to the submission contact.

Allowing a User to Assign One or More Affiliation Types to a Contact

Often a form needs to allow the user to select one or more roles to assign a contact. To achieve this:

1. Add a Contact control to the section. The Tag value is not important.

2. Add a single or multi-select nFORM control. Set the Tag to ‘AFFIL’ and set the values to one or more Affiliation Type descriptions.

When this configuration is used, the section may only contain one contact control. Otherwise, the system would not know which contact to assign the selected Affiliation Types to. The section can be set to repeating if multiple contacts with different Affiliation Types are needed.

Configuring Multiple Contact Controls with the Same Affiliation Type

Form design rules require that all tags in a form are unique, but this could cause a challenge if two or more contact controls need to be tagged with the same Affiliation Type Code. To overcome this limitation, use the + sign to add text at the end of the tag to create a unique tag value. For example, a contact control with tag CMPLNT+TEST1 will yield a contact with affiliation type CMPLNT.

Configuring a Contact Control to Update Site (Person) Details

A common scenario for license forms will require that a Contact control be used to update the Site (Person) Details. When the Applicant is also the Site, the contact control may be used to create both. To achieve this, the Contact control Label can be set to "Applicant" and Tag can be set to "SITE". 

Note: The Site Name comes from contact Company Name / Organization field. The first name/last name fields are only used for updating Person sites.  

Creating Submission Contacts and Site Relationships from a Site Lookup

See the Relating Sites in a Submission article for more information on configuring form controls to reference a list of other sites, organizations, or persons, and then create submission contacts or site relationships based on the selection in a submission.

Contact Control Field to nCORE Contact Database Field Mapping

The following table provides a mapping from individual fields on the nFORM contact control to nCORE Contact fields.

Document Integration from nFORM into nCORE

Submission PDF

nFORM produces a PDF document containing the information provided in the submission form. The naming convention of the PDF is configurable in the Form Details screen.

Submission Attachments

Document attachments are always imported from an nFORM submission and attached to the Submission record in nCORE. If a description has been provided for the document within the nFORM attachment control, the description will be carried forward into nCORE.

Integration from nCORE into nFORM (prefill)

Prepopulation from nCORE into nFORM is accomplished through nFormImport.SOURCE_[SUFFIX] views where the view name suffix indicates the section tag to populate.

Prerequisite 

To prepopulate forms, Pre-fill → Import from External Source (SQL) must be checked:

Image Added

For each Section that will require prefill, the Enable Form Pre-Fill (via Context ID) field must be checked and the Section Tag should be set to view name suffix of the source name eg. (SITE, PRMT, or FEATR, )

Image Added

Available sources are: 

• nCORE - nFORM Integration Tags#Sites

• nCORE - nFORM Integration Tags#Submissions

• nCORE - nFORM Integration Tags#Permits

• nCORE - nFORM Integration Tags#Features

• Other sources can exist depends on clients needs. 

Site Prefill into nFORM

Populated from view: nFormImport.SOURCE_SITE

Available standard data for pre-population in a section tagged SITE are:

Submission prefill into nFORM

Populated from view: nFormImport.SOURCE_SUBM

This view is primarily used for:

• Populating data about the submission's parent Schedule

• Populating the Alternate Identity in the Submission Header

• Schedule Due Date (that should typically be set to Read Only when populated)

• Schedule Name (see Notes below on what it contains)

Available standard data for pre-population in a section tagged SUBM are:

Populating the Alternate Identity with the nCORE-generated submission number

The nCORE source view nFormImport.SOURCE_SUBM can be used to populate the nCORE-generated submission number into the nFORM Alternate Identity, making this available on the Submission Wizard Header and Submission Summary screen:

1. Create a new section (or use an existing section), and tag it SUBM, and enable it for prefill

2. Create a new short-text control tagged SUBM_REF_NUM and make it "Read Only"

3. At the form version level in the "Details" Section, check box "Activate Display of Alternate Submission Identifier"

4. Check newly-displayed box "Override Display Label", and enter label of your choice 

Permit prefill into nFORM

Populated from view:  nFormImport.SOURCE_PRMT

Sections must have a Tag set to ‘PRMT’ in order to prefill permit data into the section.

Since permit information is never updated in nCORE upon submission receipt, any controls tagged for Permit data prefill controls should set to read-only.

A maximum of one permit can be specified on a form using these tags. The PRMT section should never be marked repeatable. Information about other permits can be collected on the form but the controls for these permits should be given tag values that are not in the reserved list below.

A section tagged PRMT should only be included on Permit Change forms or Compliance Schedule forms. Since Permit Change forms (e.g., modifications, renewals) and Compliance Schedules (e.g., annual reports, notifications) are typically used in the context of an existing, in-effect permit, including a PRMT section on these forms provides a convenient way of automatically displaying information about that permit on the form. For example, the permit number and effective date can be displayed at the beginning of the form so that the applicant can confirm that they are filling out the form for the correct permit.

Permit Change forms and Compliance Schedules can also contain site information, but this should be done by using a section tagged SITE containing the appropriate SITE tagged controls.

Available standard data for pre-population in a section tagged PRMT are:

Feature prefill into nFORM

Populated from view:  nFormImport.SOURCE_FEATR

Feature data can be filtered for prefill/autofill into nFORM Submissions by using a special Tag syntax on the Section where the feature type code to filter for is suffixed onto the tag after a dollar sign. For example Tag FEATR$STACK would filter only for features of feature type code STACK. 

Available standard data for pre-population in a section tagged FEATR are:

Contact prefill into nFORM

Populated from view:  nFormImport.SOURCE_CONTCT

Section Prefill

Contact data can be filtered for prefill/autofill into nFORM Submissions by using a special Tag syntax on the Section where the contact type code to filter for is suffixed onto the tag after a dollar sign. For example Tag CONTCT$BILLING would filter only for contacts with affiliation type BILLING.

Single Contact Prefill (v2023.01+)

If a contact control on any section that allows prefill is tagged XXXXX${AFFIL CODE} (e.g. APPLCNT$BILLING) then it will be prefilled with the most recently entered contact of type BILLING for that regulated entity (e.g. Site). The prefix (XXXXX) of the tag can also match the same or a different affiliation type and will be imported into nCore if so.

In summary: {Export AFFIL CODE}${ Prefill AFFIL CODE}. So for example OWNR$OWNR would prefill with the Owner contact, and would export to nCore as a new version of that Owner. If the {Export AFFIL CODE} does not match a valid AFFIL code, then it will not be pulled back into nCore, it will just remain in nForm, but still can be reported on in nVisage.