Forms is a comprehensive Identity and Access Management (IAM) solution designed to streamline and adapt to the specific workflows of your organisation.

The modern landscape of IAM requires a balance between automation and control, and Forms offers both in a way that aligns with your internal processes. IAM solutions today need to be flexible enough to manage the complexity of access control across an organisation, especially as digital environments become more intricate and regulated. Forms IAM addresses this by providing customisable workflows that can be fully automated or augmented with manual checkpoints, ensuring both efficiency and accuracy. This flexibility is crucial in industries with stringent compliance requirements, where every access decision needs to be carefully monitored and validated. Forms IAM is available both on-premises and in the cloud, giving you the flexibility to deploy the solution in the environment that best suits your infrastructure and security requirements. Whether you are looking to maintain full control over your data in an on-prem deployment or leverage the scalability and convenience of the cloud, Forms IAM adapts to your strategy.

Additionally, Forms IAM integrates seamlessly with a wide range of common identity providers and data sources, including Entra ID (formerly Azure Active Directory), Google Cloud Identity, Microsoft Azure, Active Directory, and other leading platforms. This ensures that you can easily manage and centralise access controls across your existing ecosystems, without the need for complex custom integrations. The system allows administrators to configure workflows to match existing processes within the company. Whether it’s handling new employee onboarding, access revocation, or ongoing entitlement reviews, each flow can be automated for speed or include manual approval steps for sensitive actions. This adaptability ensures that the solution integrates seamlessly with your organisation’s existing protocols, rather than forcing a rigid, predefined process onto your teams. With scalable operations, capable of managing identity and access across both small businesses and large enterprises, Forms IAM can evolve alongside your organisation as it grows or its requirements change. In today’s rapidly evolving security environment, having a robust yet flexible IAM system like Forms ensures that your organisation can handle access control efficiently while maintaining the level of precision and oversight necessary for security and compliance.

Forms is an application for digitizing administrative process flows. Typical use cases include creating users (e.g. employees, consultants, partners), editing user data, or listing “My Users” and “My Groups.”

Forms provides a powerful tool to build web-based flows that delegate administration to the individuals responsible for specific information—streamlining management and improving data accuracy.

You can also create self-service flows, including user self-registration. For example, a user can authenticate using BankID, where verified information is retrieved and used to allow the user to create their own account.

We offer several tutorial videos demonstrating how to work with Forms in various scenarios.

Note: All videos are in Swedish.

• External workforce

Release notes

Check the release notes to discover the latest updates and improvements in this version.

Breaking changes

If there are any breaking changes included in this release, carefully review them before upgrading to understand how they may impact your installation and to prepare for any necessary adjustments before or after the upgrade.

How it is connected

In order for authentication to work, a SAML SP authenticator needs to be configured. Also, SAML SP need to share first part of URI in with Forms module.

Example

Forms module has "http_context" configured to "/forms". The SAML must have it's "http_context" set to "/forms/xxx" ("/forms/auth" is a good pattern).

Typically the properties regarding authentication in Forms module will look something like this:

On the SAML SP side configuration will look like this:

Once the user is authenticated data from incoming assertion vill be transfered to the session.

NameID vill be the users login identifier. Other attributes will be put in the session where multivalued attributes is merged into a comma separated list.

Filtering access to a Flow

Once authenticated all users by default can access a Flow. Restricting is based on roles attribute in the incoming assertion. By using the "requires_role" configuration parameter on the Flow restriction control is performed comparing the incoming "roles" in the assertion and data in "requires_role" for the Flow.

One value of "role" must match "requires_role" in order for user getting access.

Use this control to manage group members for a selected groups. Note. To select the group, which often is done in a previous step, use the control Selector.

Use this control to find and selected a Microsoft Entra ID group. Note. When group is selected you might like to mange members for the group. Use the control EntraGroupEditGroupMember.

Requirements

An Entra ID module deployed with matching name as defined in "namespace".

User mapping

The logged-in user is identified by some user ID, most likely the SAML NameID attribute from SP login. This ID is used for filtering on order originator.

User mapping

The logged-in user is identified by some user ID, most likely the SAML NameID attribute from SP login. This ID is used for filtering on order attestors.

Use this control to manage users for a selected group. Note. To select the user, which often is done in a previous step, use the control EntraGroupSelect.

Requirements

An Entra ID module deployed with matching name as defined in "namespace".

An Entra ID identifier, "selected_entra_id", located in either session or flow. Data is taken from session first and flow second. selected_entra_id must reference a Entra ID group.

Install product

To install on Linux, click the following link:

Verify installation

When installation is completed, verify the following:

Below is a screenshot of the control. This is from a create step where an admin has added Clarke and Kent in two input controls. Email and Mobile number has no value yet.

Scenarions when the control can be used:

• Like above when an admin creates a new object and needs to add data about the object. You can add data controllers to an inout control to verify correct syntax, an @ for email adress, no characters for an mobile number.

• You like to display data about an object. You search an LDAP directory and display a user with data about the user. The input control can be in edit or read-only mode.

Configuration

Only updated values are sent to pipe

Data changed by user will be sent to pipe.

Supported target plattforms are:

• Container (docker, kubernetes etc.)

• Linux 64-bit

• Windows 64-bit

Fortified ID Automate

Automate enables integration with one or more systems to read, transform, and write data across connected platforms.

A common use case is reading data from an HR system to identify newly created users, then automatically provisioning these users in systems like Active Directory, Google Workspace, or Microsoft Entra ID—completely without manual intervention by administrators or end users.

Fortified ID Attest

Attest extends Forms and Automation with support for approval workflows. Instead of allowing users to be created or modified immediately, one or more designated approvers must first review and approve the request.

A typical use case is requesting access to a group that protects a resource—such as a system or service—where a group owner or administrator must approve access before it is granted.

The solution can be deployed on-premises, in the cloud, or as a hybrid. Moving between test and production environments is streamlined and straightforward.

Fortified ID Password Reset

Password Reset from Fortified ID simplifies the management of secure password reset for your organization.

Users can easily and securely create a new password through self-service without having to contact their employer's IT support.

Users with personnel responsibility (manager, teacher, partner/consultant manager) can reset passwords on behalf of another user.

Your organization becomes more efficient as the time that the end user does not have access can be greatly shortened. In addition, IT personnel can also devote themselves to more constructive and proactive work.

Install product

To install on Windows, click the following link: https://docs.fortifiedid.se/installation/windows

Verify installation

When installation is completed, verify the following:

• In Windows Services, verify that Fortified ID <product name> service exists

• In file system, verify that drive:\..\FortifiedID\<product name> exits

Note. Starting, stopping, and restarting the service are handled by Windows Services.

Overview

Certain operations or flows may be considered sensitive or require additional oversight before execution. This is where attestation becomes valuable.

Attestation enables manual review by one or more designated approvers before any automated actions are carried out. It is implemented as a configurable flow using built-in functionality.

Approvers are notified via email and receive a PDF document containing the relevant data for verification. Each PDF is tailored to the specific flow, ensuring that the information is clear, accessible, and easy to review.

Once a flow has been successfully attested, the PDF can be forwarded to an external archiving system for secure, long-term storage—ensuring traceability, auditability, and compliance.

The available dates can be limited with min_date and max_date.

The input fields min_date, max_date and data represents dates. Use input_formats to specify date format handlers. Two special format handlers are available:

• duration: Handles ISO 8601 durations e.g. P10D, -P5Y. Evaluates to todays date plus the duration.

• windows_filetime: Windows FILETIME format

Only showing used by end user

Set owned_users_only_attribute will cause control match the data from owned_users_only_attribute. Matching is done using data from owned_users_only_attribute and entra_identifier.

entra_identifier is read from session or flow. Session read first then flow.

Settings "owned_users_only_attribute":"manager", will match value from entra_identifier with id in "manager". Only showing users where user is set to owner.

Exposed data to flow

"selected_entra_id" - id of selected group

"selected_entra_displayName" - display name of selected group.

The summary step has some additional properties.

The ValuePicker is often used as a drop-down list for admins to select predefined values from. See example below.

Please refer to the common configuration of for information on how to change the look and feel of Forms.

Exposed data to flow

Object array, "entra_pending_remove" - contains data on what groups to remove from user.

Object array, "entra_pending_add" - contains data on what groups add to user.

Array data will ha the syntax:

[{"id":"1234567","displayName":"Group 1"}]

Configuration

Link to basic syntax supported using Markdown

Click following link for a number of examples on how to use markdown in a step.

Use this control to find and selected a Microsoft Entra ID user. Note. When user is selected you might like to manage groups for the user. Use the control EntraUserEditUserMember.

Requirements

An Entra ID module deployed with matching name as defined in "namespace".

Use this control to manage groups for a selected user. Note. To select the user, which often is done in a previous step, use the control Selector.

Below is a screenshot of the control. This is from a create step where an admin like to choose a manager for a user to be created.

Configuration

Configuration

Receive input

Forms receives a JWT containing data using post. The JWT is verified using the trust_store and the payload is put into the flow state. This can later be accessed using flow.my_param1 in forms, and using request.my_param1 in pipes.

Control types

Two categories of controls are available:

• Basic

Overview of Flow, Step, Control and Pipes

Flow

On a high level, Forms delivers well defined "apps" with the soul purpose simplifying a process related to an "IAM-problem". Each app is called a Flow

Add one or several labels and/or descriptions text elements to a step. Example below shows a markdowns example, one label and one description.

The example can be added as one markdown or two separate markdowns.

Configuration when one markdown

This release

Crash when selecting search and then go back in ActiveDirectorySingleSelect

Improved error handling when selecting users.

All steps and summary pages use a layout grid with a base column width of 12. All controls, or children, can be specified to have different sizes and multiple breakpoints for different screen sizes.

All controls (or children of the grid) have a base width of 12, meaning that they fill the entire width of the grid. A child with the width of 6 will occupies half of the grid, a child with the width of 8 will occupy 2/3s of the grid.

The grid will fill its columns from left to right and fit up to 12 columns in each "row".

Sizes for the controls can be set in the ui [SKRIV HÄR, måste kanske ändra en grej i hur man konfar kommer jag på nu.]

All controls will be rendered into the layout according to the order that they are defined.

Each breakpoint (a key) matches with a fixed screen width (a value):

Generic HTTP module configuration is found here

Forms module handles loading of multiple Flow. Multiple instances of Forms module can be deployed.

• AuthN, version 2025.38 - details is found here

• Pipes, version 2024.115 - details are found here

• Http client, version 2025.29 - details is found here

Install product

To install on Container/Docker, click the following link:

Verify installation

When installation is completed, verify the following:

Example markdown:

Prerequisites

WorkOrder module deployed.

Create a flow used for attestation (accept/reject) using Attestor control.

Flow description

Configure last PIPE sending data to work order database and possible notifying user.

Configure one accept pipe to be executed once the work order is attested

Configure one reject pipe to be executed if order is rejected

Sending data to work order

Instead of performing updates directly, data used must be send to work-order database. Two thing are required for this:

• A PDF file used to visualise what is about to happen if accepted. Either use Html2Pdf valve for dynamic creation or use a static PDF file.

• In the last PIPE in the flow use

Accepting a work order

Once all attesters accepted the work order, accept pipe will be executed. Any flow data from order creation is present along with additional static data.

Accessing data sent from "work flow accept" is done using pattern {{request.xxx}}

Note that the accept pipe is executed in system context. No session with user data will be present.

Rejecting a work order

It only takes one attester to reject for the order to be rejected. Once rejected the reject pipe is executed. Here you can configure notification if desired.

Frontend format validation.

By setting config.format, it guides the user entering value following a defined ruleset. A predefined set is available:

• date: full-date according to .

• time: time (time-zone is mandatory).

• date-time: date-time (time-zone is mandatory).

• iso-time: time with optional time-zone.

Setting a custom regex is done using config.pattern to regex

Example:

"pattern":"^[A-Za-z -]{3,30}$"

• Start (^) and end ($) exactly with

• Only contain uppercase letters (A–Z), lowercase letters (a–z), spaces, or hyphens (-)

• Have a length between 3 and 30 characters

Once set, custom error message needs to be put in for displaing a functional error message:

In this case "phone.error.format".

Requirements

An LdapClient module deployed with matching name as defined in "namespace".

Configuration

Exposed data to flow

Object array, "ad_pending_remove" - contains data on what members to remove from group.

Object array, "ad_pending_add" - contains data on what members to add to group.

Example data in finalize pipe:

Valves used in finalize pipe

ActiveDirectoryAddGroupToMembers

Used to add group members to a specified group

ActiveDirectoryRemoveGroupFromMembers

Used to remove group members from a specified group

Searching for object to show

To populate list of items in UI a pipe must be executed. List of items returned should at least contain properties defined in columns.

Data sent to pipe is:

• search - containing user input if config -> search is set to true

• columns - comma separated string of defined columns

Return data must be in a form of a list of items.

Data exposed to flow

When pressing Select, data exposed to flow is found using key if control id. Value is item id returned from pipe

Ui

For row ordering according to columns use the following type of configuration. In this example the rows will be sorted first by email, then name, phone and lastly date_of_birth. You can also see the configuration example in the example above in the properties table examples.

Exposed data to flow

Object array, "entra_pending_remove" - contains data on what groups to remove from user.

Object array, "entra_pending_add" - contains data on what groups add to user.

Array data will ha the syntax:

[{"id":"1234567","displayName":"Group 1"}]

Use this control to manage groups for a selected user. Note. To select the user, which often is done in a previous step, use the control EntraUserSelect.

Requirements

An Entra ID module deployed with matching name as defined in "namespace".

An Entra ID identifier, "selected_entra_id", located in either session or flow. Data is taken from session first and flow second. selected_entra_id must reference a Entra ID user.

Requirements

An LdapClient module deployed with matching name as defined in "namespace".

Configuration

Configuration

Setting up a flow

The Flow is defined by a JSON file. Name of the file can be anything, but flow.json is a recommended name. Format of the data inside must be either JSON or JSONC. The flow.json file will be picked up, loaded and exposed by the Forms module.

Before step 1

Sometimes it is necessary to perform some kind of logic before first step is rendered. Typically used for validation and or collecting data reqired in step 1.

For case like this use pre_pipe.

In order to consume data in subsequent steps, make sure the pipe returns one item. Data in this item will be accessible using {{flow.xxx}}

Creating a step

A step is represented by a json object. Steps can be loaded from one json file or multiple files. Recommended setup is to keep each step in a single file. This will simplify configuration and overview.

Pipe execution

If configured, execution of a pipe is done with all data available to the step. This means data will vary depending on what step is executed.

Data from all previous executed steps will be sent to pipe and accessed in pipes using {{request. pattern.

Returning from pipe execution

In order to be able to access any data returned from a pipe, return a single item in a pipe.

Data will available using {{flow.xxx}} pattern.

Skipping execution

A step can be enabled/disabled using the "enabled" flag. Both the page user interface and the pipe-execution is disabled if this flag is false.

Skipping execution conditionally

You can also enable/disable a step conditionally using the "include_expr"-expression (an expression that returns true or false). If the expression is evaluated to true, the step is included, otherwise skipped.

The actual filter is an ECMA-script (JavaScript) that MUST evaluate to true, false or to a boolean function returning true or false.