Importing and Exporting#
You can import and export items into a variety of systems, including Excel tables, MS project files and other Allegra instances.
Importing Items from Excel#
You can import items from Excel tables. If Allegra recognizes that an item from the Excel table already exists, it will not be created anew, but will be modified if necessary.
To create items from an Excel worksheet, the sheet must contain the required data. The first row of the table contains the field names, all subsequent rows contain item data, one item per row. If possible, make sure before importing,
that all individuals in the Excel table are given in the format “Last name, First name”
that all individuals in the Allegra system are created as users
that the individuals in the project you want to import into have appropriate roles as managers or responsible
that all date fields are given in the format YYYY-MM-DD
If the table contains a PSP column, the PSP code determines the hierarchy level. You do not need to specify unique numbers. For example, all items on the first level could have a PSP code “1”, all items on the second level “1.1” and so on.
Importing items from Excel#
To import items from an Excel sheet, go to the item overview and drag the file to be imported onto the right area of the navigator.
Select the sheet within the Excel file from which you want to import items.
Allegra will try to map all columns in your Excel sheet to corresponding fields. You can control this mapping process manually. Allegra will remember your last mapping definitions and reuse them in all subsequent imports. All subsequent imports then no longer require a mapping step.
In the next step, you determine how Allegra should handle required values that it cannot find in your Excel worksheet. There are two options: either the row is rejected or a default value is inserted.
If there are problems with the table, you will receive hints from Allegra on the affected row and the data. You can then correct the table and re-upload the file.
If all goes well, Allegra will create an item from each row of the worksheet. You can only import system and user-defined fields. It is not possible to import editors and readers as well as efforts or budgets.
You do not need to enter a project in your worksheet. You can select a project for all positions during the import process.
The order of the columns is not important. However, you should keep the order the same in all imports to minimize configuration effort.
The column headings should be assigned to the corresponding Allegra fields. If a column header is not assigned, the values from this column will not be imported.
Allegra tries to assign the column headings of the table to its own fields as best as possible. For this comparison is considered
the localized field configuration (localized field labels)
the non-localized field configuration (original field labels)
the field names
If Allegra cannot find a suitable mapping, you can manually supplement the mapping. The import wizard displays the field labels as in the Allegra global scope.
As soon as the “Next” button is clicked, the created mapping is saved in a user-specific directory and used as the default assignment for the next import.
Composite fields are contained in a single column. The various sections of a composite field must be separated by a “|” character.
For multiple value fields, all values are contained in the same cell. The different values must be separated by commas (“,”).
Each table row is validated in several steps before an item is created from it.
It is checked whether all required fields are present. This means that they are either defined in the table and connected to the required field, or you have selected that default values should be used if there are no values in the table.
For each cell value, it is checked whether it is valid. The specific handling depends on the type of cell.
Label (text) fields: Selection list entries are indicated by their labels. For persons, the format “Last name, First name” applies. It is checked whether an entry with this label exists. If it exists, it is checked whether it is valid or not. For example, it is checked for the manager that this person actually has manager rights in this project and so on.
Boolean (checkbox): The Excel cells should either be of the Boolean type or the text value should be “Y”, “N”, “true” or “false”.
Numeric fields: Either the Excel cells must be of the digit type, or the number format should match the user’s locale or it should be in ISO format. Other values are interpreted as text as they appear in the cell.
Date fields: The Excel cells should either be of the date type or the date format should match the user’s locale or the date should be in ISO format (YYYY-MM-DD).
It is checked for each row whether this item already exists. The most robust identification is possible if you carry the Allegra item numbers in your Excel sheet. If this is not possible, you can define a combination of identification columns that should uniquely identify each item.
For example, you can combine the author, the project, and the title as a unique identifier. This implies that these three fields are not changed between re-imports and that their combination is unique. If no matching item is found, a new one is created. If a matching item is found, the changes from the non-identifying columns are transferred.
Each row is validated against the regular field validators before it is added, just like when creating an item from the user interface.
If all the validations described above were successful, the row is created or modified as a new item in the Allegra system.
When importing data from an Excel sheet, conflicts may occur, for example when Allegra recognizes an Excel row as an existing element, but there are conflicting data within this item between the Excel version and the Allegra item.
If there is no column for the last edit date in the Excel sheet, no usable history data is available. In this case, if there is a conflict with a field value, the system cannot decide on its own which value is more current.
If there are data for the last edit date in Excel, Allegra can perform intelligent conflict resolution, as it can take into account the chronological order in which changes have occurred. The handling differs for fields for which an explicit history is activated is Allegra , and those that are without explicit history. You can select an explicit history for all fields, but this is not the default.
If field history recording is enabled, Allegra resolves conflicts as follows:
It is checked whether the first old value from the Allegra history (after the last edit date) is the same as the actual value from Excel. If the values match, then the change was only made in Allegra and not in Excel. Consequently, the Allegra value is silently retained, and the user will not be asked for conflict resolution. Otherwise, the user will be involved in conflict resolution.
If a field does not have explicit history recording, field changes are only recorded in the common history recorded. For such fields, there is no reliable way to find out whether they were only changed in Allegra or also in Excel. So if after the last edit date in Excel there is at least one common history entry, any changed field without explicit history is subject to conflict resolution.
If there is no history data since the last edit, Allegra overwrites the values with those from the Excel file without conflict resolution.
Importing Data from Other Allegra Installations#
You can import data from another Allegra installation, for example to merge two different installations. This powerful operation can have far-reaching impacts on the importing system and is therefore only accessible to system administrators. This section describes what happens during this type of import.
Allegra allows you to take over items and all associated data from one instance to another. In the following, we refer to the Allegra instance from which the data comes as the source system. The receiving instance we refer to as the target system.
Importing data from other Allegra instances#
To import data from another Allegra instance, you must be logged in with system administrator rights be logged in, e.g. as an admin user. DANGER: When importing data from another Allegra instance, among other things, users, workspaces and configurations are infiltrated into the target system. However, the users are deactivated.
Please also note the following:
Input forms and form assignments are not imported. Therefore, you may not see some fields that are visible in the source system.
Allegra tries to compare all objects from the source system with its own objects to avoid duplication of items, users, attributes, etc. Users are identified by the combination of login and email. Most other objects are matched by their universal unique identifier (UUID). Custom list entries are matched by their labels. Items are not matched by their item numbers, but by their UUIDs.
In the import process, all item numbers are read first. Embedded links (i.e., those to items in the description text) and other links are not adjusted and imported if they refer to items not included in the imported data set.
If you specify a custom field of type “Text” in your target system and call it “OldTrackID”, the item numbers of your exporting instance will be stored there as a reference. In addition, a file in ALLEGRA_HOME is written with a mapping with the new item numbers and the corresponding old item numbers.
If the import data set contains workspaces that are not present in the target instance, these areas are newly created. In this case, each role that is used in the source system and not present in the target system is added. The users are assigned exactly the roles in these new projects that they also had in the source system.
No role assignments or roles are added for existing projects.
New users are added as deactivated users.
The import process can only add data, no data is deleted. If, for example, attachments have been deleted in the source system since the last synchronization, these attachments remain active in the target system.
To import data from another instance, drag the source ZIP file into the right area of the navigator.
The data in the file is imported into your Allegra instance and merged with the existing data.
Export to an Excel File#
You can export the items shown in the item overview to an Excel file.
Mark the items to be exported. Only marked items are exported.
Click on the “Action” button and select from the menu Export > Excel.
Download the Excel file to your local computer. You can open this file directly in Excel or OpenOffice.
The Excel file contains all current properties of the items selected in the item overview. The Excel file does not contain any change history due to the limitations of the format.
Export to a CSV File#
You can export the items shown in the item overview to a CSV-formatted file for import into applications that can read this format. Note: You can set the delimiter used in the CSV file in your personal profile area as it may depend on your version of MS Office and the locale on your client computer.
Click on the “Action” button and select from the menu Export > Export CSV.
Download the CSV file to your local computer. You can open this file directly in Excel or OpenOffice.
The CSV file contains all current properties of the items shown in the item overview. The CSV file does not contain any change history due to the limitations of the format.
Exporting in Allegra Format#
You can transfer data from one Allegra installation to another. Allegra allows you to take over items and all associated data from one instance to another. In the following, we refer to the Allegra instance from which the data comes as the source system. The receiving instance we refer to as the target system.
Exporting items to another instance#
To prepare an export, please note the following:
You must be logged in as a user with system administrator or system manager rights (e.g., user admin)
You must have at least read access for each area from which you want to export items.
To export, you first create a list of the items to be exported in the item overview using a filter. In the selection column on the far left, mark the items to be exported. Note in the case of a hierarchical view, that it is fully expanded.
The export process creates a ZIP file with all data and attachments, which you can import into the target installation.
Exporting items to another instance (2)#
Go to Actions > Export > Export in Allegra Format in the toolbar. A download field appears.
Exporting items to another instance (3)#
Save the file to your local drive. In our example, this file has a size of about 9 MB. The size depends very much on the size of the attachments. This file can later be imported into the target system.