Teams

On the Infraon platform, a team consists of users grouped together. Teams can be categorized based on a reporting manager, technical skills, support level (L1, L2), role, etc. These are the foundations for managing user groups responsible for handling various ITSM operations such as approvals, ticket resolutions, change implementations, and release activities.

Users are assigned to multiple teams, and teams are assigned to specific modules.

What you see on the screen

The Teams page lists all existing teams and offers options to filter, search, add, or manage teams individually or in bulk. From this page, you can view, add, edit, and delete existing pages.

Teams | Basic Details

Label	Action	Description / Example
Bulk CSV Update	Click to download/upload template	Enables mass editing or creation of teams. Steps: Click Bulk CSV Update Download the CSV template Fill in the required team data Upload the modified CSV to apply changes
Add Team	Click to open the team creation form.	It opens the "Add Team" configuration page, where you can manually create a new team by selecting a module, team type, and members.
Team Name	View only	Displays the name of the configured team. Example: Default Approval Team.
Module	View only	Indicates the module the team is associated with, for example, ticket, change, and contract management.
Type	View only	Specifies the team's functional role, such as Approval, CAB, Technical, or Servicedesk.
Description	View only	Displays an internal note about the team’s purpose or assignment scope. Example: All changes will be visible to this team.
Edit	Click to modify the existing team.	Opens the edit screen to update the module, team members, type, or description.
Delete	Click to remove a team	Deletes the selected team from the inventory.

Instructions to 'Add Team'

To add a new team, navigate to the Teams page and click the Add Team button at the top right corner. This opens the Create Team window, where team information and functional attributes can be defined.

Create Team

Create Team | Basic Details

Label	Action	Description / Example
Team Name*	Enter the team name.	Mandatory field. A unique identifier for the team. Example: IT Service Desk – L1, Network Change Review Board.
Group Email ID	Enter shared group email (optional)	Used to send email notifications to multiple members. Example: [email protected]. This should be a distribution group.
Description*	Enter description	Add notes or context about the team. Example: Handles all L1 ticket escalations for the Bangalore region.
Module*	Select from the dropdown	Choose the module to which the team belongs. Example options include: Ticket, Change, Problem, Service Request, Release, Live Chat, etc.
Team Type*	Select from the dropdown	Choose the type of team from the available classifications. See the Team Type Tab below for more details.
Owners of the Team*	Select responsible users	Mandatory. These users manage the team’s structure, approvals, and visibility rules.
Department	Select from the dropdown	Assign the team to a specific business department. Example: IT, Facilities, Procurement.
Business Hour Profile	Select applicable time profile	Maps the team’s operating hours, which impact SLAs and ticket routing. Example: 24x7, Weekdays 9 AM–6 PM.

Fields marked with an asterisk (*) are mandatory.

Team Type

Team types define the role the team plays across various modules and workflows. When creating or editing a team, select the appropriate team type.

Team Type | Add Teams

Team Type	Purpose	Usage Example
Approval	Users are responsible for reviewing and approving requests, changes, or releases.	Used in Request, Change, or Release modules as part of approval chains or thresholds.
Operational and Technical	Users who execute operational tasks, such as troubleshooting or maintenance.	Assigned to incident resolution, asset handling, or technical tasks in Ticket, Problem, or Project.
Servicedesk	Frontline users who log, categorize, assign, and respond to service tickets.	Typically used in Ticket or Live Chat modules.
Review	Users involved in periodic review processes, compliance checks, or validations.	Used in Knowledge Base, Change Management, or Problem for formal assessments.
CAB	The Change Advisory Board is responsible for reviewing and approving regular changes.	Used in Change Management for predefined change approval workflows.
Expert	Subject matter experts performing advanced-level configurations or troubleshooting.	Ideal for complex issue resolution in Change, Problem, or Release.
ECAB	Emergency CAB for urgent changes requiring immediate approvals.	Critical for fast-track Emergency Changes in Change Management.

When a Team Type is selected, the system dynamically displays different configuration options based on that type. The configuration page adapts based on the team’s role, ensuring only the relevant options for that specific type are shown.

Location

Users can associate the team with a specific location. This helps in aligning team responsibilities based on regional or site-specific operations.

The section contains two dropdown fields:

Label	Action	Description / Example
Location Category	Select a location category from the dropdown	Defines the category under which the location falls. Example: Country, Region, State, etc.
Select Value	Choose the value based on the selected category	Displays location options based on the chosen category. Example: India, USA, Bangalore.

Multiple values can be selected depending on the team’s configuration. For example, a regional support team can be associated with the South and North regions.

Service Request/ Ticket Location Mapping

How It Works

• Admin configures teams with appropriate location categories and values (e.g., Region: South, Location: Bangalore).

• When a user raises a service request or ticket, their default or selected location is matched against team configurations.

• The system automatically assigns the request to the team mapped to that location.

• The team receives the ticket for further action without requiring manual routing.

The system determines the location using one of the following methods:

• Asset Location – If the request/ticket is raised from a specific asset, its location is used.

• Requester Location – The default location configured for the user is referenced.

• Service Request Location – A location selected manually during request creation is considered.

Example Use Case

• A user from “Mumbai – Tower A – 2nd Floor” requests printer support.

• The system detects their location (requester) and checks against team mappings.

• That location is mapped to the “Facility Support – West” team.

• The service request is instantly routed to the correct team, ensuring minimal resolution delays.

Staff Selection

While creating a team, admins must configure the team members who will be part of that group. The Staff Selection section offers two configuration tabs to define how staff are added.

Label	Action	Description / Example
Staff Selection	Choose between User Tags or Users	Determines how team members are assigned. User Tags: Automatically includes users who are tagged with the selected criteria. Users: Allows manual selection from all active users in the system.
Staff	Select from the dropdown.	Choose the appropriate user tags or individual users from the list based on the selected method. Example (User Tags): L1 Support, Network, Linux Admin Example (Users): John Smith, Anita Rao

Expertise

This configuration helps identify the team’s core skills and areas of specialization (such as ITAM, NMS, NCCM, Log Management, etc). It also allows you to establish a hierarchy of support staff members who will receive notifications and assist in resolving module-specific tasks.

Label	Action	Description / Example
Expertise	Select from the dropdown or enter to add a new expertise	Identify the domain or technical skills for the team. Example: ITAM, NCCM, Log Management.
Add Tag	Enter the tag name and select the type.	When adding new expertise, input the tag name (e.g., log management), select the Type as Group, and then click Submit.
Enable send notifications to additional internal/external users	Toggle to activate	When enabled, notifications can be sent to selected support staff even if they are not directly assigned to the task.
Select Expertise	Choose an expertise tag from the dropdown.	Determines the expertise area being configured for the support hierarchy. Example: ITAM.
Description	Enter a short explanation (optional)	Provide additional information about the expertise. Example: Handles hardware asset tracking.
Add Users	Select users for the support hierarchy level.	Choose users to notify or assign responsibilities within a level.
(+) Icon	Add another hierarchy level	Add multiple levels of escalation or expertise-specific staff. Example: Add Level 2 with different users.
Add	Click to add another expertise mapping.	Configure support hierarchy for multiple expertise tags (e.g., ITAM and NCCM).

Approval Sequence

An approval team is a group of designated staff members responsible for reviewing and approving requests. Team members are added as staff and can be assigned a specific approval sequence to ensure requests follow a structured approval flow.

Label	Action	Description / Example
Approval Sequence	Click the toggle button to enable	Activates the option to define multiple levels of approval. Once enabled, you can add users in the order in which approvals are to be received.
Sequence 1	Select from the dropdown	Choose the first-level approvers for the team. These users will be prompted for approval first. Example: Abdul, Abhirup, Alex Carry
Add	Click to add additional sequence rows.	This option allows adding second-level (or more) approval steps. The approval request will move to the following sequence only after the prior sequence is completed.
Sequence 2, 3...	Select users for each additional sequence	Define second-level or third-level approvers as needed. Example: Sequence 2 – John Doe, Sequence 3 – Team Lead

Advanced Configuration

Percentage-Based Approval Sequence

In enterprise environments where actions require team approvals, waiting for unanimous consent can delay critical operations. The Infraon platform makes this process more flexible, configurable, and scalable for team sizes and business needs.

What is Minimum Approval Percentage?

The Minimum Approval Percentage setting defines the minimum percentage of team members who must approve a request or action for it to proceed.

How Does It Work?

When a request (like a change, ticket, or service approval) is sent to an approval team:

• The system checks the total number of approvers in the team.

• Based on the configured percentage (e.g., 60%, 80%), it calculates how many approvals are needed.

• If that number of users approves, the action is automatically accepted, even if other members have not responded.

This mechanism enables faster decision-making and reduces bottlenecks in workflows.

1. Response Required (Toggle Switch)

• Enabled (ON):

The system will wait for all team members to respond before proceeding. This is suited for highly sensitive workflows where a unanimous or whole team review is mandatory.

• Disabled (OFF):

The system only waits until the minimum percentage of approvals is received. Once that condition is met, the action is approved and executed, even if other members haven’t responded.

Recommendation: Keep this OFF for dynamic or time-sensitive workflows.

2. Minimum Approval Percentage

This dropdown field allows you to choose the threshold (e.g., 50%, 60%, 80%, 100%). You can set values based on your organization's comfort level with partial consensus.

Example Breakdown:

• Team Size: 5 Approvers

• Minimum Approval: 60%

• Required Approvals: 3 (rounded from 60% of 5)

• If three members approve the action, the system considers it valid, even if the remaining two have not taken any action.

If three members reject the request, the system will trigger the rejection flow since achieving the required 60% approval with only two remaining approvers is impossible.

The UI will display:

“Minimum 3 from 5 users' approval needed to complete the action” — updated dynamically.

Use Case Scenario – Infraon

Background

Infraon uses Infraon Infinity to manage internal change requests for production systems. Its Change Advisory Board (CAB) includes 10 infrastructure, security, development, and QA team members.

Challenge

Usually, only 3–4 core members actively participate in reviews. Waiting for all 10 members to approve often delays release cycles.

Solution

Using the Percentage-Based Approval feature, Infraon configures:

• Minimum Approval Percentage: 70%

• Response Required: OFF

Result

• The system only needs 7 out of 10 members to approve.

• Even if the remaining three do not respond, the change is processed promptly.

• This reduces approval cycle times from 3 days to under 1 day.

• It aligns with their internal governance policy without slowing down DevOps.

Notes

• Security-sensitive requests still follow a 100% response policy (Response Required = ON).

• Infraon uses different thresholds for different teams using team-specific configurations.

• Set lower percentages for large and cross-functional teams to streamline decisions.

• Set higher thresholds or turn on "Response Required" for high-risk or compliance-critical workflows.

• Communicate the approval logic to team members to avoid confusion or delays.

Automatic Ticket Assignment

This configuration tab is enabled when adding an Operation and Technical Team.

Operation and Technical Team - Used to configure auto-assignment of tickets.

What is Auto Assignment?

An alert is raised when a ticket lands in the service desk queue. Either a technician self-assigns it, or a team leader assigns it to the team. With manual intervention, tickets may be picked based on ease of resolution, making it unfair for other technicians. New tickets may also be in the queue for too long while waiting to be assigned, impacting the SLAs. Auto assignment of tickets removes manual intervention, ensuring fairness and timely assignment. Infraon offers three methods to define auto-assignment.

Round Robin

Round Robin is the simplest way of assigning tickets, where tickets are assigned equally to active technicians in a circular order. It is recommended for businesses where tickets are raised to follow up on orders, requests, etc. Using this to auto-assign tickets helps save time on the manual assignment of tickets.

Use-case - An e-commerce business where tickets are raised to know order status, delays in delivery, or refund status, etc. Since these are information-based tickets and no troubleshooting is required, the time spent on each ticket is minimal. Using the Round Robin method ensures that tickets are assigned equally and orderly.

Load Balancer

The load-balanced method assigns tickets based on the technician's load and is recommended for businesses offering a wide range of services, where the resolution time is different for each. Using the Load-Balanced method ensures that the technicians have a balanced workload while working on a ticket. When a new ticket is raised, the technician with the least load is auto-assigned. Tickets are assigned based on the ticket queue's SLA, priority, and criticality. Thresholds must be defined to select this method.

Use-case - A technical support center for a product that offers 24/7 support where tickets are raised throughout the day. Some tickets may be inquiries, while others might have a long resolution. A round-robin method may not make sense here. The load balancer method checks the technician's current load before assigning new tickets. This way, technicians are not burdened with work.

Skill Based

The skill-based method is used when the organization offers multiple categories/levels of support. It is recommended for organizations providing support globally or across a wide range of products/services. Skill-based assignment ensures that the right technician assigns the tickets by matching their skill and level.

Use-case - A business that offers support or services on multiple products, regions, and time zones, offering multi-lingual support. Here, tickets must be assigned based on the skill of the technician. The technician must be skilled in the language selected by the customer, know about the product chosen, etc. A skill-based allocation is best platformed for this.

Delegate Configuration

This tab allows administrators to set up backup approvers or staff in case the primary team members are unavailable. Delegation ensures continuity of operations by routing approvals or tasks to alternate users.

Label	Action	Description / Example
Delegate To Owner	Toggle to enable	This allows the delegation of approval or responsibility to the team owner. When enabled, tasks are redirected to the team owner.
Delegate To Staff Member	Toggle to enable	Enables delegation to a specific staff member. Useful when designated approvers or team members are unavailable.
Delegate From	Select a user from the dropdown	Choose the user whose tasks or approvals will be delegated. Example: Select John Smith (Team Approver)
Delegate To	Select an alternate user from the dropdown	Choose the delegate who will take over the responsibilities. Example: Delegate to Jane Doe (Alternate Approver)
Add	Click the add (+) button	Adds the selected delegation pair to the team configuration. You can define multiple delegation rules.

Delegation is typically configured for team types such as Approval, CAB, and ECAB, where approval chains must be maintained.

Once all fields are added, click Submit to finalize the team setup.