IT landscape settings¶

The IT landscape settings page lets you customize the dropdown values used throughout IT Landscape. These lists control what options appear when users create or edit Applications, Interfaces, Assets, Connections, and Locations. Changes here apply to all users in your workspace.

For map readability, Entities and Server roles also include a Graph tier field used by the Connection Map's role-based placement.

Where to find it¶

Workspace: IT Landscape
Path: IT Landscape → Settings
Permissions:
You need at least settings:reader to view the page.
You need settings:admin to change values.

If you don't see the Settings entry in the IT Landscape drawer, ask your administrator to grant you the appropriate permissions.

How the page is organized¶

The Classifications and continuity editor sits at the top of the page. Below it, lists are grouped into four collapsible sections:

Locations - Lists used when creating or editing locations.
Servers & connections - Lists used for servers, connections, and related risk/endpoint data.
Apps, services & interfaces - Lists used across applications, app instances, interfaces, and bindings.
Incidents - Lists used by the incident register.

Within a section, lists are sorted by name. Each list appears as an expandable panel with a short hint that says where its values are used (for example, Applications / Category selector). Click a panel header to expand it and see the values. Only one section loads its content when you first expand it, which keeps the page fast even when you have many lists.

Editor controls¶

Each list has its own controls at the top:

Add item - Inserts a new row at the top of the list, focused and ready to type.
Edits save automatically about a second and a half after your last change, once every row is valid. A saving indicator shows next to the list.

For long lists (more than 25 rows), the table virtualizes rows, showing about 20 at a time with smooth scrolling and sticky headers.

Names are the identity of a value¶

You only ever see and type names. KANAP generates a stable internal code from the name when a value is first saved and keeps it forever, so renaming a value never breaks the records that use it. The code is visible to integrators in the API and can be used in CSV files, but the CSV export writes names and the import accepts either.

Because names identify values, a few rules apply within a list:

every value needs a name, and two values cannot have the same name (case does not matter);
a name cannot be identical to the internal code of another value in the same list;
names of Access methods cannot contain a comma or a semicolon, because the CSV export lists them in one comma-separated cell.

A list that breaks one of these rules is not saved until you fix it; the row shows what is wrong.

Removing a value¶

Remove deletes a value that nothing uses. When records still reference the value, KANAP shows how many (applications, assets, interfaces, connections, sites, incidents, subnets…), with a link to the filtered list where a list can be filtered on that field, and offers No longer offered instead: the value stays visible on the records that already use it and is no longer proposed for new ones. A value in use is never removed, even through the API.

Built-in values that KANAP manages itself (the four lifecycle statuses, the Workgroup and N/A domains) cannot be edited or removed. Default network zones and asset types can be edited and retired but not removed: the server would add them back.

Translating your values¶

The values you type are shown as is in every language. To show them in the language of each user, use the Translate action on a row: the dialog shows the base name (and description for classification levels) and one field per language. A field left empty uses the automatic translation when the value is still a KANAP default, otherwise the base text. Saving translations never changes the base text, and a translated name can be used in CSV files and the API like the name itself, which is why it must not duplicate another value of the list.

Editors always show and edit the base text; when the displayed name differs for your language, the row says so ("Shown: …").

Locations¶

Cloud providers¶

Cloud providers used by servers and locations (e.g., AWS, Azure, GCP).

Columns: Name, No longer offered

Where used: - Assets workspace → Overview tab → Provider field - Locations workspace → Overview tab → Cloud provider (when hosting type is cloud)

Hosting types¶

Location hosting models available when creating locations (e.g., on-prem, colocation, public cloud, SaaS).

Columns: Name, Category (On-prem / colocation or Cloud / SaaS), No longer offered

Where used: - Locations workspace → Overview tab → Hosting Type field

The category determines which fields appear when editing a Location: - On-prem / colocation shows Operating Company and Datacenter fields - Cloud / SaaS shows Cloud Provider, Region, and Additional information fields

Servers & connections¶

Connection types¶

A two-level catalog (category and entry) of connection protocols, with typical ports.

Columns: Category (e.g., Database, Remote Access), Name, Typical ports, No longer offered

Where used: - Connections workspace → Connection Type selector

The Typical ports field is free text - you can enter single ports (443), lists (80, 443), ranges (9101-9103), or placeholders like multiple or specify.

Default categories include: Application, Authentication, Backup, Database, Email, File Sharing, File Transfer, Messaging, Monitoring, Network Services, Remote Access, Replication, Storage, VPN / Tunnel, Generic.

Domains¶

Active Directory or DNS domains for assets. Built-in entries cannot be modified. The DNS suffix is used to compute the fully qualified domain name (FQDN) for each asset.

Columns: Name, DNS suffix, No longer offered

Where used: - Assets workspace → Technical tab → Domain selector - Assets workspace → Technical tab → FQDN (auto-computed from hostname + DNS suffix)

System entries (cannot be modified or deleted): - Workgroup - For standalone assets not joined to a domain - N/A - For asset types where domain membership doesn't apply (e.g., network devices, racks)

Auto-fill behavior: When adding a new domain, the DNS suffix auto-fills from the name you enter until you edit it yourself.

Example: A domain named "Corporate AD" with DNS suffix corp.example.com would produce an FQDN of hostname.corp.example.com for an asset with hostname web-server-01.

Entities¶

Endpoints used in connections and maps (e.g., Internal Users, Internet, Partner Networks, External Systems). The graph tier sets their default placement on the map.

Columns: Name, Graph tier, No longer offered

Where used: - Connections workspace → Source Entity and Target Entity fields - Connection Map → entities appear as flow endpoints and use their graph tier for vertical placement (default entities are Top)

Graph tier values¶

The graph tier controls the preferred vertical band in Connection Map when Role-based placement is enabled:

Top: Most user-facing or external endpoints
Upper: Upper application/service layer
Center: Neutral/default middle layer
Lower: Supporting infrastructure
Bottom: Data/storage-heavy endpoints

IP address types¶

Types of IP addresses for assets. Useful for distinguishing between different network interfaces like host IPs, management interfaces, and storage networks.

Columns: Name, No longer offered

Default values: Host, IPMI, Management, iSCSI

Where used: - Assets workspace → Technical tab → IP Addresses section → Type dropdown

Assets can have multiple IP addresses, each with its own type. For example, a physical server might have: - A Host IP for application traffic - An IPMI IP for out-of-band management - An iSCSI IP for storage network connectivity

Network zones¶

Network zones used to categorize subnets and describe connectivity (e.g., LAN, DMZ, Industrial LAN, WiFi, Public Cloud, Guest, Management, Storage, VPN).

Columns: Name, No longer offered

Where used: - Subnets list → Network Zone selector - Assets workspace → Technical tab → Network Zone (auto-populated when subnet is selected)

Subnets¶

Define network subnets with CIDR notation and optional VLAN assignments. Each subnet belongs to a network zone and to a location.

Columns: Location, CIDR, VLAN (1-4094), Network zone, Description, No longer offered

Where used: - Assets workspace → Technical tab → Subnet selector

Validation rules: - CIDR must be valid IPv4 notation (e.g., 192.168.1.0/24) - VLAN numbers must be between 1 and 4094 - CIDR and VLAN numbers are unique per location (same values can exist at different locations)

Auto-population: When you select a subnet on an Asset, the Network Zone is automatically populated from the subnet's configuration.

Operating systems¶

Catalog of operating systems available for servers, with standard and extended support end dates.

Columns: Name, Standard support, Extended support, No longer offered

Where used: - Assets workspace → Technical tab → Operating System selector (helper text shows support dates)

Dates are stored as YYYY-MM-DD but displayed and edited as DD/MM/YYYY.

Default entries include Windows Server versions, Ubuntu LTS, RHEL, Debian, and SLES with appropriate support dates.

Server roles¶

Roles assigned to servers when linking app instances (e.g., Web server, Database server, Worker). The graph tier sets their placement on the connection map.

Columns: Name, Graph tier, No longer offered

Where used: - Applications workspace → Servers tab → Role dropdown when linking an asset to an instance - Connection Map → role-derived placement band for servers and clusters

Default built-in examples: - web, proxy → Top - app, cloud-service → Upper - db → Bottom

Asset types¶

Logical types for servers and infrastructure assets (e.g., Physical server, Virtual machine, Container, Serverless, Appliance). Physical assets can track hardware and support information.

Columns: Name, Physical, No longer offered

Where used: - Assets workspace → Overview tab → Type field

Apps, services & interfaces¶

Access methods¶

Methods by which users access applications (e.g., Web, Mobile, VDI).

Columns: Name, No longer offered

Default values: Web, Locally installed application, Mobile application, Proprietary HMI (industrial interface), Terminal / CLI, VDI / Remote Desktop, Kiosk

Where used: - Applications workspace → Technical & Support tab → Access Methods multi-select field

Tip: Customize access methods to match how your organization categorizes application access. For example, add "Citrix" or "Thin Client" if those are common access patterns in your environment.

Application categories¶

Categories that describe the primary purpose of each application or service.

Columns: Name, No longer offered

Default values: Line-of-business, Productivity, Security, Analytics, Development, Integration, Infrastructure

Where used: - Applications workspace → Overview tab → Category field - Applications list → Category column and filter

Tip: Customize categories to match your organization's terminology. For example, rename "Line-of-business" to "Business Applications" if that's how your team refers to them.

Classifications and continuity¶

This editor configures the levels used to classify applications. It is available to settings:admin users at the top of the page and opens as a single dialog with one list per catalog:

Business criticality: the levels an application can be assigned. Each level has a name, a description shown under the name when choosing a level, an optional maximum tolerable downtime in minutes, and a No longer offered flag. The downtime documents the level and triggers a warning on an application whose RTO reaches it; it is an attribute of the level, not a value entered on applications.
Cyber criticality: independent consequence levels.
Data confidentiality: the data classes catalog, with descriptions.
Recovery waves: ordered restoration stages. The order does not represent severity or a time estimate.

Order is the position in the list. Severity catalogs are listed from the most critical level at the top to the least critical at the bottom; recovery waves in restoration order. Use the arrows to move a level; the position drives the sort order of lists, the "highest level" rule used by interfaces and connections, and the order of the pickers. Add level appends at the bottom.

Changing the catalog never changes applications. An application stores the code of its level. Renaming a level, editing its description or downtime, and reordering the catalog leave every application on the same level and do not invalidate reviews. A level still used by an application, interface or connection cannot be removed; mark it No longer offered instead: it stays visible on existing records and is no longer proposed for new ones.

Codes are generated from names and never shown; the naming rules above apply.

The business levels also power operational criticality on interfaces and connections. Missing derived inputs are marked incomplete; they are not treated as the lowest level.

Data confidentiality¶

The Data confidentiality list holds the data classes used by applications and interfaces. The built-in levels (Public, Internal, Confidential, Restricted) cannot be deleted or deprecated.

Where used: - Applications workspace → Compliance tab → Data Class field - Interfaces workspace → Overview tab → Data Class field - Applications list → Data Class column

Integration patterns¶

Integration patterns used by interface legs (e.g., REST API, File batch, Queue, DB staging).

Columns: Name, No longer offered

Where used: - Interface legs → Pattern field

Interface authentication modes¶

Authentication modes for interface legs and bindings (e.g., Service account, OAuth2, API key, Certificate).

Columns: Name, No longer offered

Where used: - Interface bindings → Auth Mode field

Interface data categories¶

Business data categories for interfaces (e.g., Master Data, Transactional, Reporting, Control).

Columns: Name, No longer offered

Where used: - Interfaces workspace → Data Category field

Interface data formats¶

Data formats for interface legs (e.g., CSV, JSON, XML, IDoc, Binary).

Columns: Name, No longer offered

Where used: - Interface legs → Format field

Interface protocols¶

Supported protocols for interface bindings between applications (e.g., HTTP/REST, gRPC, SFTP, Kafka, Database).

Columns: Name, No longer offered

Where used: - Interface bindings → Protocol field (legacy bindings)

Interface trigger types¶

Trigger types for interface legs (e.g., Event-based, Scheduled, Real-time, Manual).

Columns: Name, No longer offered

Where used: - Interface legs → Trigger field

Lifecycle statuses¶

Shared lifecycle options for applications, app instances, interfaces, interface bindings, and servers.

Columns: Name, No longer offered

Locked codes: The built-in statuses (Proposed, Active, Deprecated, Retired) cannot be deleted or have their codes changed.

Where used: - Applications, App Instances, Interfaces, Interface Bindings, Assets → Status fields

Incidents¶

Incident categories¶

Categories used to classify entries in the incident register.

Columns: Name, No longer offered

Where used: - Incidents → Category selector

How changes affect existing data¶

Existing records keep their value - Renaming only changes what users see, not the underlying data.
Values marked No longer offered:
Remain valid for records that already use them.
Are hidden from dropdowns when creating new records.
Still appear during edits if the record already uses that value.
New values become immediately available in the relevant dropdowns and are validated server-side.

This approach lets you evolve your taxonomy over time without breaking existing records.

Quick reference: which list powers which field¶

List	Where it's used
Access methods	Applications (Technical & Support tab → Access Methods)
Application categories	Applications (Category)
Cloud providers	Assets (Provider), Locations (Cloud provider)
Connection types	Connections (Connection Type)
Domains	Assets (Technical tab → Domain, FQDN)
Entities	Connections (Source/Target Entity), Connection Map (graph tier placement)
Hosting types	Locations (Overview)
Integration patterns	Interface legs (Pattern)
Interface authentication modes	Interface bindings (Auth Mode)
Interface data categories	Interfaces (Data Category)
Interface data formats	Interface legs (Format)
Interface protocols	Interface bindings (Protocol)
Interface trigger types	Interface legs (Trigger)
Incident categories	Incidents (Category)
IP address types	Assets (Technical tab → IP Addresses → Type)
Lifecycle statuses	Applications, App Instances, Interfaces, Bindings, Assets
Network zones	Subnets (Network Zone), Assets (auto-populated from subnet)
Operating systems	Assets (Technical tab)
Subnets	Assets (Technical tab → IP Addresses → Subnet selector)
Server roles	Applications → Servers tab (role when linking asset to app), Connection Map (graph tier placement)
Asset types	Assets (Overview → Type)

Tips¶

Align names with your terminology - Review the defaults and rename values to match how your organization talks about these concepts. Records keep their link to the value; only the name changes.
Retire gradually - When transitioning away from a value, mark it No longer offered rather than removing it. This keeps historical data intact while steering users toward new options.
Coordinate data classes with security - Changes to data classes should align with your information security policies. Discuss with compliance before adding or renaming classification levels.
Use typical ports as documentation - The Typical ports field of connection types is informational. Fill it in to help users understand what ports each connection type commonly uses.
Tune map readability with tiers - Keep the graph tiers of entities and server roles aligned with your architecture layers (edge, app, data) for clearer Connection Map layouts.