Why does import adds columns with 'u_' prefix?

[vks]

I'm working on a scoped application. I'm trying to import data in ServiceNow via an XML file. I have created an import set table with all possible columns and have defined transform map to transform this data into ServiceNow tables.

However when I execute an Import, the import process ignores my columns in the staging/import set table and adds new columns with 'u_' prefix. Why does it do this?

I could find the property glide.import_set_row.dynamically_add_fields which could prevent creation of new columns but I'm not sure if disabling this option would force import to use my columns, my guess is import would fail.

My question is why does the import creates new columns when I have columns in the import set table and if I disable dynamic creation of columns how could I instruct import to use my columns?

Thanks,

Vipin

[Deepak Ingale1]

Hi Vipin,

Since in scoped apps, already a whole table is created with namespace prefix, SN might not have added the logic to apply prefix to columns. That makes sense since tables which are high level entity are already prefixed with namescape prefix.

[vks]

Exactly.

Now with this same philosophy the Import Set table names in a scoped app shall be prefixed with namespace - which is the case.

And columns in these Import Set tables shall no more require any prefix (u_ or namespace) - but that is NOT the case. SN ignores any columns without u_ prefix and creates them.

[Deepak Ingale1]

Hi Vipin,

Yes, staging table gets created with namespace and custom columns gets created with u_ prfix.

Strage, but not sure why it happens like this for import set and scoped app.

But, are you facing any issue due to this mechanism?

[vks]

Hi Deepak,

No, I'm not facing any issue but before I prefix my columns in staging tables with 'u_', I wanted to confirm that this behavior is as per SN design and there is/are no setting(s) to prevent this.

If that assurance is there, I can justify having my columns u_ prefixed and create transforms based on this.

Thanks,

Vipin

[Deepak Ingale1]

Okay.