# System Configuration Customize your language and time zone settings on Infraon. The module offers a centralized location for administrators to manage various user experiences and formatting settings for different modules within the Infraon Infinity platform. Here's a breakdown of the key functionalities: ## Language and Time Zone Admins can define the default language and time zone for the entire platform, ensuring a consistent user experience. ## Timeout Set the duration of user inactivity before automatic session lockout to enhance security and prevent unauthorized access to open sessions. ## Assets


Label	Action	Description / Example
Enable Ticket Creation for Out-of-Warranty Assets	Click to turn on/off the toggle button.	When enabled, the system allows ticket creation for assets that are out of warranty. Example: If disabled, users cannot raise support tickets for laptops whose warranty has expired.
Enable Ticket Creation for Out of AMC Assets	Click to turn on/off the toggle button.	Ensures tickets cannot be raised for assets that are not under an active Annual Maintenance Contract (AMC). Applies to both Self-Service and Technician Portals. Example: If enabled, a user cannot raise a ticket for a printer that is not covered under AMC.
Enable Ticket Creation for Expired User Contracts	Click to turn on/off the toggle button.	Restricts users with expired contracts from raising new tickets. The system validates the contract status automatically. Example: If a user’s support contract expired last month, they will not be able to submit new tickets.

## Module Formatting This powerful feature allows for customization of how specific data is formatted within various Infraon modules. For example, admins can define prefixes for modules like Tickets, Assets, Requests, etc. These prefixes will be displayed instead of the actual names within the portal, potentially improving organization and clarity for users. Additionally, formatting options for these modules can be configured, providing granular control over how information is presented. The following section breaks down the details: For instance, admins can configure these formatting preferences * Ticket The Ticket module automatically closes tickets that remain in the **Resolved** status for a defined period. The system calculates the duration based on configured business hours and closes the ticket once the time is completed. Auto-closure starts from the **first business hour after resolution** and excludes weekends, holidays, and lunch breaks.\ \ All system-initiated closures are logged in the ticket activity history. **Auto-Closure Settings** The following fields are available in the Ticket module under **System Configuration → Formatting.**


Label	Action	Description / Example
Resolved tickets auto-close after the 1st SLA Business Hour in	Select the duration using Business Days and Hours	Defines when a ticket in the Resolved status should be automatically closed. The countdown begins from the first business hour after resolution. Example: 2 Business Days, 1 Hour → Ticket will close after completing this duration within defined business hours.
Select filter for aging time calculation	Choose the ticket status from the dropdown.	Determines which status is used to calculate the ageing time for auto-closure. Example: Selecting Resolved means the timer starts once the ticket enters the Resolved state.
Activation Status	Displays activation state	Shows whether auto-closure is active for the Ticket module.
Prefix	Enter or customize prefix	The prefix used when generating ticket numbers. Example: TKT results in identifiers like TKT6023.
Preview	View example output	Displays a sample ticket identifier and layout with the applied prefix.

* Asset * Prefix * Request * Prefix * Resolve ticket will close automatically in (1,2,3….) days * Select a filter for aging time calculation (Resolved, Closed) * Change * Prefix * Problems * Select a filter for aging time calculation (Resolved, Closed) * Releases * Prefix * Risks * Prefix * Tasks * Prefix * Knowledge Base * Prefix Once the changes are made to satisfaction, click “Save” to proceed. ### **CLI Jobs** The **CLI Jobs** allow administrators to define the default behavior and restrictions for command-line interface (CLI) jobs. This configuration ensures that access durations, idle timeout, and session frequency are consistent and secure across the platform. Action Icons | Basic Details


Label	Action	Description/ Example
Idle Session Timeout (Minutes)	Enter a value (dropdown)	Defines how long a CLI session remains active without any interaction. Example: 15 minutes.
Active Duration Begins	Select from the dropdown.	Sets the starting point for job duration calculation Options available: From First Access Time and From Approval Time.
Default Job Active Duration (Hours, Minutes)	Enter values (dropdown)	Sets the default time for which a CLI job will remain active. Default: 0 hours 30 minutes.
Default Job Access Count (0 is unlimited)	Enter a numeric value	Defines how many times a user can access the job. Setting `0` allows unlimited access.

### **NCCM Module Configurations** These configurations manage upload jobs, CLI job restrictions, and request approval workflows in the NCCM module. #### **Disable Upload Jobs** It prevents the execution of upload jobs and restricts any device configuration changes through the upload functionality.


Label	Action	Description/ Example
Disable Upload Jobs	Toggle ON/OFF	When enabled, all Upload Jobs are blocked from execution. Used to restrict unapproved config pushes.

#### **Disable CLI Jobs** Blocks users from executing CLI jobs, adding an extra layer of control for sensitive operations.


Label	Action	Description/ Example
Disable CLI Jobs	Toggle ON/OFF	Prevents execution of CLI-based configuration changes through the system interface.

#### **Create Approval Request / Get Approval Request Status / Update Job Result** These three sections work together to integrate NCCM with an external approval system through API calls. You can configure endpoints and expected payloads to initiate approvals, check their status, and update results once they are actioned. Action Icons | Basic Details


Label	Action	Description/ Example
Approval Method	Select from the dropdown.	Choose how approval requests are handled. Options include: · Third Party Integration: Approval is managed via an external system through API. · Use Infraon Change Request: Uses Infraon's native Change Management module for CAB-based approval.
Select API	Select from the dropdown.	Choose the registered API that handles the approval request or status updates.
Method	Select HTTP method	Supported methods: `GET`, `POST`, etc., depending on your API design.
Endpoint	Enter the API endpoint.	The complete endpoint path for the selected method. Example: `/api/approval/start`.
Content Type	Select content type	Usually, application/json defines the format of the request payload.
Content for CLI Jobs / Upload Jobs	Enter the payload with macros.	JSON structure with macro variables (e.g., `@@@job_name@@@`, `@@@approval_status@@@`) passed during the job request.
Expected Response for CLI / Upload Jobs	Enter response format	Define the expected response from the API for a successful status update or result pushback.

#### **Update Approval Status** This section helps the NCCM system update the job’s approval status dynamically once a request is approved, rejected, or pending in the external system.

Label

Action

Description/ Example

Content for Job

Define response body

Typically includes the job name, approval status, and change ID.

Example:

{

"job_name": @@@job_name@@@,

"approval_status": "@@@approval_status@@@",

"change_id" : @@@change_id@@@

}

## **Disable SSP 2FA** Two-Factor Authentication (2FA) adds an extra layer of security to requester accounts in the **Self-Service Portal (SSP)** by requiring a time-based one-time passcode (TOTP) from an authenticator app. The availability of the 2FA option in the requester’s **Account Settings** depends on the **organization-level configuration** set by the administrator. **Behavior Based on Org Settings**

Org Setting	Result in SSP	Example
Disable Requester 2FA = Enabled	The 2FA toggle in the requester’s account settings is disabled. Requesters cannot activate two-factor authentication (2FA) on their accounts.	Admin has disabled requester 2FA for the organization → requesters see the toggle as disabled.
Disable Requester 2FA = Disabled	The 2FA toggle in the requester’s account settings is enabled, allowing requesters to set up and use two-factor authentication (2FA).	Admin allows requester 2FA → requesters can enable 2FA for their accounts.

* The **2FA toggle** is dynamically enabled/disabled based on org-level configuration. * Admins maintain centralized control to enforce or relax requester 2FA usage. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.infraon.io/infraon-help/infinity-admin-guide/infraon-platform/system-configuration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.