---
# System prepended metadata

title: Improvements of HF system

---

# Improvements of HF system

## Requirements

- let people fill out digital forms
- prefill forms with already collected data
- harmonize data (defined data model for each payload)
- HF independent user/group mgmt
- SDK to integrated HF with existing applications (SMT Desktop/mobile etc)
- share data with external systems in a reliable way (connecting messaging systems)

## Dual strategy

To reduce dependency on HF we need to think of alternative solution, especially that HF does not meet our expectations.

1. HF
2. Build own tool based on open source components available on the market

Currently we are building some of the parts on our side to be able to:
- generate forms out of defined semantic
- automate deployment process of the forms via Jenkins


### HF

#### Problems

- authorization token is statically embedded in stage file
- authorization token is per instance not per incident which expose security risk
- when form is created in HF manually we do not have ways to link the information back
- lack of SDK to embed HF functionality into our product
- Duplicated user management which is based on AD
- links not working when technician has an HF user and had an active session in the browser / app.
- HF does not support universal link and we can't lead user to the iOS app
- HF is strongly build on M$ platform which makes it hard to deploy on premis
- No API to change permissions on a form template for users and groups


### SMT

#### Problems

- user mapping information from SMT to HF user is stored in HF only
- no way to connect existing HF users to SMT users
- no way for a SMT user to create exactly the form that they want. Whatever form(s) are created when a ticket is created in SMT is defined in the database and cannot be changed within the SMT app
- we can create HF users within SMT, but those users are created in the default HF user group. No mapping to any user group or company is possible
- every single existing form template requires an own data model. Prefilling forms and extracting data from forms is a task that is taking too long every time. Also fixing problems during prefilling is too much work.
- need to create thousands of forms for the maintenance because most of the users are not SMT users and need a link to the form in order to see it, because the don't have credentials to their HF user.
-- if there are problems in those form with prefilling, a script has to written to change them.
-- users requirements are prefilling email addresses: Needs a seperate script to change the recipients on already created forms. 

