overview to assist with importing data into the system, there is a range of functionality to help with getting the data, into the tables and format that you require this can assist with importing data from a spreadsheet, via ldap or other integrations that you may utilise this is done in a three step process which starts with importing data via a data source, which will enter a staging table that you can review, which ends with using a transform map to help it populate its destination to help describe this process, this article will use the steps from a spreadsheet, but this mechanism can also be interacted with other methods if required data sources the first steps with defining a source where data can be imported from these data sources can either be added manually prior to the initial import, but can also be created at the same time as the initial import for the purpose of this article, it will detail both options, but start with creating the data source dynamically and using an excel document for this example (and remainder of this article), we will use the below spreadsheet to import 2 new starters into the organisation import data to start off this process, proceed to the import data menu item from here, you will need to create or select a staging table, as well as select or create an import source as this article assumes you are doing this for the first time, it will detail it from creating a new staging table and data source, but note that if you want to reimport a file, or have these already defined, you can also use this page and mechanism to reimport from a data source although this will be detailed in more detail later, if you are creating a staging table, you generally want to give it a name that is identifiably a database table and not used as a result we generally recommend something along the lines of dataimport however, you can make it whatever is unique before attaching the excel file as a document, we generally recommend considering the following prior to attaching a file remove any styling, formatting or anything that may impact the data being imported ensure there are no formulas in the document (although technically supported, we typically suggest only importing values) ensure any column with data has a column heading when possible, cleanup the data to import keep in mind however, when we get to the transformation stage, you can transform the data as you want import using 1 tab and having the column headings in row 1 you will also notice there are other options on this page, however typically you can ignore the display xls/csv settings, if you follow our recommendations, this can be ignored in addition to this, there is also a section where you can use any existing transform maps immediately after using the import this can be used if you already have a transform map in place, but for this example (given that you would be creating a staging table at the same time), would not be used once done, press submit and a popup will come up (note that you don’t need to wait for this, as it happens in the background, but it normally makes sense to leave it so you can complete the next steps when done) once imported, you will be provided with the following page, where you can then see the log, staging table and data source any imports that you do, will have an import data source (which you can access in the menu with the same name) if you are doing multiple imports from the same source, we typically suggest you update the data source, rather than always creating a new data source and staging table therefore, in the example you may import a spreadsheet, but then later decide that you need to update it you can access the data source via the menu, update the attachment and then in the first step use “existing staging table” and “existing import source” it should be noted that if you are importing with other data sources or otherwise, you will also need to use this page, but you would most likely create the data source, prior to the initial import staging tables staging tables within the system allows you to view the data, prior to it entering the source you can access any staging table created via the “import staging table” menu item in short, staging tables, although are tables within the system, are built for the purpose of importing data, so you would never need to create any fields manually, or create any functionality about it in the running example we are using, if we look at the staging table that was created when we imported the excel document, you would see the following screen it should be noted that every row / record of the data source will translate to one record in this table as a result, once you have transformed the data and even before then, you may look at the data within this table, to understand what has been imported or not imported accordingly to explain the purple buttons and their purpose view records this allows you to see any records that have entered the staging table, their data, and then their status and target (once transformed) this is typically used to help understand if data didn’t import the way you expected to, the reason why and / or understanding what record it updated it is imported to note, as the staging tables are generated differently to normal tables, you may need to refresh your browser before field labels appear correctly it should also be noted, as every historical import record will be here, you will often see “duplicate” records, but may be because you imported the same data multiple times delete temporary table this deletes the staging table and any records within the staging table (not the target table) generate temporary table this generates the staging table this is normally not required, because as you import data, it will automatically generate it reset state this will reset the state of every record within the staging table from every import therefore making it that the next time you import, every record will be reimported warning as this resets the state of every record, this can cause you to import a lot of records unnessacarily and therefore not recommended unless you have only 1 import worth of data there delete records this will delete any record within the staging table (not the target table) as these tables can grow quite substantially overtime, we recommend setting up a table cleanup record for each of your staging tables see system table cleanup docid\ o1s krobssx9dljg4m3d1 transform maps to allow data to get into the target table, you need to create a transform map there are a few different ways to do this, however, for the purpose of this example, it will detail the manual method, to provide insight as to how the parts all hang together to create a transform map the manual way, go to the transform maps menu item once on this screen, you’ll want to give it a name (for informational purposes), description and source and target table as a starting point the source table will be the staging table created, whilst the target table, where you want the data to go then, you will need to generate are the field mappings first, start with the mapping(s) for unique/primary key it is important that you have a unique key that you can use to import, to avoid duplicate data in the primary table to configure which field mapping will be used as the unique key, you can mark the mapping via the use of the “primary key” checkbox on the field mapping we suggest that you also use this for mappings that are of type "copy" multiple fields can be a primary key, in case you need to ensure it is a combination of fields, rather than a singular one what you use as the key needs to be unique, e g for importing users, it should be like their username or email addresses, instead of their name for importing data with identifying numbers such as contracts or old ticket references, you may want to use those contract or ticket numbers/ids there are three different types for different purposes, however, for all of these, you will want to pick the target field copy copy is simply a copy of the data from the source field (data source) to the target field the data won’t be transformed or altered in any way lookup lookup allows you to look up a table to assist in populating reference fields to do this, you will need a source field, target field, as well as detailing what table it will need to lookup and based on what field the field you lookup doesn’t have to be display value of the lookup table, however, you will normally want it to be unique (such as an identifier or name or otherwise) when using the lookup import transform mapping type, you can also create the record if it doesn’t exist so in the below example, it would create company, with the company name that didn’t exist in the system lookup multiple lookup multiple allows you to look up a table to assist in populating multiple reference fields to do this, you will need a source field, target field, as well as detailing what table it will need to lookup and based on what field the field you lookup doesn’t have to be display value of the lookup table, however, you will normally want it to be unique (such as an identifier or name or otherwise) when using the lookup import transform mapping type, you can also create the record if it doesn’t exist so in the below example, it would create company, with the company name that didn’t exist in the system for lookup multiple fields, you can populate add multiple references at once to do this, you simply need to add a “|” in between each reference you want to add an example of this, lets just say we want to add nicholas smith to group1, group2 and cab groups within the excel spreadsheet it would look as per below transform transform provides the most capabilities in terms of what you can do in transform maps, as this allows you to script an value for the target field in this example, a source field is optional, but if you set it, you get easier access to it from here, you have access to the table api (server) so you can do any lookups you need to in addition to this you have access to “value”, which will be the value of the source field for a given row, and row, which is an object which holds any column value for a given row such as in the below example, we are getting the company name we used above to generate an employee name to set the field, you will need to set the answer variable in the script, you have access to the following variables variable name description row a key/value set of the fields and their values, with the key being the field name, and the value being the string value of the record from the import example answer = `${row\ firstname} ${row\ lastname}`; // will return 'bob smith' if firstname is bob and lastname is smith rowindex the current index of the record in the transform starts at 1 rowrec a reference to the tablerecord of the row in the staging table can be useful when the script requires more information than may be available in the ‘row’ object current the target record object transform scripts should avoid making any direct changes to this record, but it may be useful to use this record to look at other related information log a log object that allows the transform script to record entries in the ‘import load log’ mapping a reference to the current import mapping transform record targettable the name of the target table being referenced value the string value of the related field from the staging table answer this variable should be set to the value you wish to set the target field to example mapping a value to a choice field’s option if for example that you have a choice field, and you are importing the label (not the key), you can import those using a transform type with the following script the script queries the “availablevalue” table which stores choice field’s choices/options the query is filtering against the choice field we are mapping to and the choice label we are mapping for the return value would be the choice key to apply to the choice field if (value) { let availablevaluerec = table("availablevalue") and( equal("table", mapping parent() target()), equal("field", mapping targetfield()), equal("value", value) ) query(); if (availablevaluerec next()) { answer = availablevaluerec key value(); } else { answer = ""; }} else { answer = "";} pre process script pre process scripts can be used to perform logic before the transforms commence they can also be used to instruct the transform process to skip the row but returning the value ‘false’ or ‘skip’ in the answer variable example below if (row\ username == "admin") { answer = skip; } below lists the available variables in a pre process script variable name description row the import row/record that is being transformed e g if an import record has a field "description", then it can be accessed like below row\ description rowindex the current index of the import record in the transform starts at 1 rowrec a reference to the tablerecord of the import ow in the staging table can be useful when the script requires more information than may be available in the ‘row’ object current the target record object pre process script should avoid making any direct changes to this record, but it may be useful to use this record to look at other related information log a log object that allows the transform script to record entries in the ‘import load log’ targettable the name of the target table being referenced answer set to ‘skip’ or ‘false’ to skip the record for the transform note that you can apply a tablechecks docid iboxr6adyjx8fev0jeym into the transform process, such as not to run trigger, by applying it in a pre process script example below of a pre process script to run a table check current disabletriggers(); let checkstouse = tablechecks notablechecksnosystemfieldsnochecksnoevents withevaluatefieldvalues(true); current tablechecks(checkstouse); post process script pre process scripts can be used to perform logic after the transform of an import row/record is completed they can also be used to instruct the transform process to skip the row but returning the value ‘false’ or ‘skip’ in the answer variable below lists the available variables in a post process script variable name description row the import row/record that is being transformed e g if an import record has a field "description", then it can be accessed like below row\ description rowindex the current index of the import record in the transform starts at 1 rowrec a reference to the tablerecord of the import row in the staging table can be useful when the script requires more information than may be available in the ‘row’ object current the target record object you can make changes to the "current" transformed record, here on the post processing script note that you need to excute the update() function for your update (or for workflow\ forcetoactivity() function, you can set third parameter as true) log a log object that allows the transform script to record entries in the ‘import load log’ example below shows a post processing script to force the transformed record, that has a workflow, to a workflow status of "in progress" workflow\ forcetoactivity("closed", current, true, false); final import step once the transform map has been set up, you can proceed to the final step to use the transform map to get the data from the staging table, over to the target table to do this, go to the “run data load…” menu item from here, you need to select a transform map, staging table, and transform type typically you would want to select the import load type of “sync”, which will create / update any records, rather than one or the other once done, press submit and a popup will come up, similar to what came up when you imported data into the data source and when completed, will show you a screen for quick access to the log or otherwise at this point, the data should be in the target table based on your transform mapping if it doesn’t appear as you like, remember to look at the staging table and the logs to understand what the record looked like prior to entering the system and / or any log messages that came up scheduling imports if you want to schedule imports (although not a valid use case for the spreadsheet example provided through out this article), you can schedule the import of data (data source → staging table) and the transformation (staging table – (via transform map) > target table) separately or together this is done via the scheduled imports and import scheduled loads menu items respectively note that you should never have these run every minute and we typically suggest when scheduling imports as you need it (normally every day) if you need data updated to the minute, we instead suggest that you push that data from the source system via a rest api (or otherwise), rather than using this method