The third-party system "HR Made Easy" is used by companies A, B, and C. The system archives an employee's entire personnel file.

Independent company: Company A wants to use its own archive for data protection and compliance reasons.

Companies B and C, on the other hand, will be merged. As the personnel administration for both companies is based on a central administration, the employees of both companies should be able to search in all archives at the same time (see IndexGroup in the table).

GmbH A has a pre-defined field schema, as no further fields are to be added in this system. GmbH B and GmbH C also have a pre-defined field schema. However, it should be possible to define new fields in the "HR Made Easy" system. It should be possible to add the fields to the index (field value search). It should also be possible to search in the fields (see Fixed index field schema: Yes / Support Free Fields in the table).

The documents for company A should be deleted automatically after 10 years. The documents for companies B and C should be deleted after 7 years (see retention period in the table). The documents of company A must be versioned due to the GDPR. However, the documents of companies B and C do not (see versioning: Yes / No in the table).

The personnel files of company A contain standard forms that are identical (with the same hash value). The size of the forms per file is 12 MB. The archive "A personnel file" contains 80,000 personnel processes with an average of 5 versions (i.e., 400,000 files stored in the archive). For a form that is 12 MB in size, 4.8 TB of data volume is taken up by forms alone. Single instance is therefore activated, reducing the required storage space to 960 GB.

The archive of B and C also contains 80,000 processes, but without standard forms. In addition, there are currently very many accesses due to the merger. Single instance is therefore not activated. Otherwise, a hash number comparison between the document to be archived and the documents already archived would be carried out for each access with single instance. This would affect the access times (see Single Instance in the table).

At GmbH A, settings have been made to keep old versions from being searchable via a field search, removing all old versions from the index. The old versions can then only be found via the document ID. As the BC archive is not versioned, nothing else needs to be taken into account here (see Delete Last Version from Index in the table).

Company A always wants the current version to be displayed when calling up the personnel file (see Last version in Query in the table). In addition, company A requires the option of loading specific versions or all versions in the extended search (see Specific version in query in the table). The last two considerations do not apply to B and C, as versioning is not used here.

The following shows which system can best map which business cases with different company forms, as well as the corresponding number of separate archives.

Below you will find brief explanations of the archive configurations used.

xSuite Archive Prism is a schema-free archive. The field information that is transferred from a third-party system is automatically created in the index with the specified data type. This field information can also be used for a search. The definition of a schema (i.e., a document type with permanently defined fields), is possible via the DocumentTypes configuration node. Fixed fields can be defined here. During configuration, you can also specify that fields may be created via the third-party system.

A retention period (see Retention in the table) can be defined for the archive or for a document type. Configuration depends on archive content. If multiple document types with different retention periods are stored within an archive, the retention period can also be set at document-type level.

A new version is created each time an index field is changed. The attachments are also duplicated.

If "Single Instance" is configured, archive document attachments will only be duplicated during versioning if the attachments are not identical. This is ensured by an MD5 hash check. The check applies to the archive as a whole (meaning that an attachment can be assigned to multiple archive documents). This only works in conjunction with the storage format (StorageType) FileBox.

Restricting indexing to the current version of an archive document is only possible in conjunction with versioning. Documents are versioned, but can only be found via document reference, not via the index. This saves storage space and is therefore useful for large amounts of data.

If the current version of an archive document is always to be displayed during the search, there must be a check as to whether this is possible due to specific requirements of the third-party system. To do this, activate the index property TopVersionFlag and the hit-list property ForceTopVersionFlag. You have the option of selecting this property when defining the hit list in the REST call (HitlistDescription → ForceTopVersionFlag).

If all archive document versions are to be displayed during the search, check whether the requirements of the third-party system allow it.