Service management system having a form-creation interface including field sorting and selection functionality

Embodiments described herein relate to service management systems and, in particular, to form builders within service management systems.

Help desks and issue tracking systems may allow enterprises to organize and manage their workflows, such as for information technology applications. However, one challenge with traditional issue tracking systems is providing an efficient user interface that collects the right amount of information from the user in order to ensure prompt resolution of the technical issue. Some traditional systems request too much information for some tasks and too little information for other tasks. The systems and techniques described herein can be used to quickly tailor an intake interface using an administrator tool that can be used to more easily generate new or modified intake flows for an electronic help desk.

Embodiments described herein may be directed to systems and methods for automatically selecting and sorting fields in a service management system. An administrator may create and edit intake interfaces in a help desk platform and may create and edit issue item fields related to the issue intake interface. In some cases, in accordance with an authenticated user account having administrator access with respect to the service management system, an intake interface builder graphical user interface may be displayed. The intake interface builder graphical user interface may include a field region configured to display a plurality of field elements and a request editing region configured to receive field elements from the field region in response to a drag-and-drop user input. In some examples, the request editing region may include user input regions of an issue intake interface of a help desk platform. Next, a first subset of field elements of a plurality of field items may be selected. The selection of the first subset of field elements may be based on prior user event history with respect to the service management system. A second subset of field elements from the first subset of field elements satisfying a selection criteria may then be selected. The selection criteria may be based on, at least in part, field element selections performed by the authenticated user account within a predetermined time period. At the intake interface builder graphical user interface, the selected second subset of field elements may be displayed and in response to receiving a first user input of a first field element of the second subset of field elements, the first field element within the request editing region may be displayed while display of the first field element within the field region may be suppressed. In some embodiments, in response to receiving a second user input comprising a confirming creation of the intake interface input, an issue intake interface may be generated. The issue intake interface may include an input field corresponding to the first field element when displayed by the help desk platform.

According to some examples, the user account may be a first user account. In some cases, in accordance with an authenticated second user account having customer access with respect to the service management system, the issue intake interface may be displayed. In response to receiving, at the issue intake interface, a customer input to create a new issue item: a first window having a form comprising an intake interface input field may be displayed and in response to a user selection of the issue intake interface from the intake interface input field, a set of user input fields including the input field corresponding to the first field element may be retrieved and the input field may be automatically configured in accordance to a format. In some examples, in accordance with receiving a second customer input to at least one user input field of the set of user input fields, an issue item at an issue tracking system may be generated.

Embodiments described herein may include a method for suggesting field elements in an intake interface builder of a service management system. In some cases, subsequent to authenticating a user account having administrator access to the service management system, an intake interface may be accessed via an intake interface builder graphical user interface. In some cases, the intake interface builder graphical user interface includes a field region configured to display a plurality of selectable field elements and a request editing region configured to receive at least one selectable field element from the plurality of selectable field elements in response to a user input. The request editing region may define user input regions of an issue intake interface of a help desk platform. A set of selectable field elements of the plurality of selectable field elements may be selected and sorted. The selecting and sorting may include: for a first subset of selectable field elements, applying a weighing metric to each respective selectable field element, the weighing metric based, at least in part, on a frequency of use of the respective selectable field element and a time period of use of the respective selectable field element; and selecting a second subset of selectable field elements from the first subset of selectable field elements based on the weighing metric and a selection criteria. In some examples, the second subset of selectable field elements may be displayed at a top region of the field region. In response to receiving a first user input of a first field element of the second subset of field elements, the first field element may be displayed within the request editing region and display of the first field element within the field region may be suppressed. In response to receiving a second user input comprising a confirming creation of the intake interface, an issue intake interface may be generated which includes an input field corresponding to the first field element when displayed by the help desk platform.

Embodiments described herein include a method for displaying field elements in an intake interface builder graphical user interface. As described, the method may include: Subsequent to authenticating a user account having administrator access to a service management system, accessing an intake interface via an intake interface builder graphical user interface. In some cases, the intake interface builder graphical user interface may include a field region configured to display a plurality of field elements, each field element of the plurality of field elements may be configured to be dragged from the field region to a request editing region, each field element of the plurality of field elements may include a graphical representation of field items available in the service management system and request editing region which may be configured to receive at least one field element from the plurality of field elements in response to a user input. The request editing region may define user input regions of an issue intake interface of a help desk platform. The method may further include selecting a subset of field items from a set of field items that satisfy a selection criteria, the selection criteria may be based on each field item used within a predetermined period of time with respect to the service management system. The selected subset of field items may then be sorted according to a sorting criteria based on a date used for each field item and a predicted relevance with respect to the user account. The sorted subset of field items may be displayed as a first subset of field elements within the field region. In some cases, in response to receiving a first user input including a first field element of the first subset of field elements, the first field element may be displayed within the request editing region and the first field element may be suppressed from display in the field region. In response to receiving a second user input configuring creation of the intake interface, an issue intake interface may be generated that includes an input field corresponding to the first field element when displayed by a help desk platform. In response to the user selecting the intake interface within the help desk platform, the issue intake interface may be automatically displayed and the input field may be automatically configured according to a format. In some cases, in response to a customer confirmation, the issue item including the user input within the input field may be created.

The use of the same or similar reference numerals in different figures indicates similar, related, or identical items.

The use of cross-hatching or shading in the accompanying figures is generally provided to clarify the boundaries between adjacent elements and also to facilitate legibility of the figures. Accordingly, neither the presence nor the absence of cross-hatching or shading conveys or indicates any preference or requirement for particular materials, material properties, element proportions, element dimensions, commonalities of similarly illustrated elements, or any other characteristic, attribute, or property for any element illustrated in the accompanying figures.

Additionally, it should be understood that the proportions and dimensions (either relative or absolute) of the various features and elements (and collections and groupings thereof) and the boundaries, separations, and positional relationships presented therebetween, are provided in the accompanying figures merely to facilitate an understanding of the various embodiments described herein. Accordingly, they may not necessarily be presented or illustrated to scale and are not intended to indicate any preference or requirement for an illustrated embodiment to the exclusion of embodiments described with reference thereto.

Embodiments described herein relate to systems and methods for displaying field item recommendations. In particular, the systems and methods described here recommend and sort field items in an intake interface builder of a service management system. These field items may be displayed as field elements in the intake interface builder, which creates intake interface forms, also referred to as intake interfaces. Upon creating the intake interfaces, the intake interfaces become available in a help desk portal and define the interface within the help desk portal and can be used to define the interface and fields of issues tracked by an issue tracking platform once the issue is created.

IT and enterprise service management systems are effective tools for managing, supporting, controlling, and delivering services. These service management systems may include a series of applications which support different functions of the service. For example, a help desk application may allow users or service agents to report an issue within an enterprise. An issue tracking platform may manage those issue items, assign issues to service agents to resolve, allow viewers to view the status of their issue items, and the like. In many of the above applications, each issue item and each intake interface includes a series of fields which allow users and agents to collect information for routing and resolving issues. Fields also allow systems to create a knowledge base that streamlines future work. In some cases, fields can be searched and filtered to quickly retrieve relevant items.

However, as the size of an organization grows and as the needs of each team and/or project changes, new fields may need to be created to capture specific information or to adapt to new issues of the larger organization. For example, a team working in hardware development may create a field for hardware service life. A team working on software for a game may include a field for known glitches and/or chapter of the game where a glitch was found. As new fields are developed, it may be increasingly difficult for administrators to find existing fields that meet their project needs. In many cases, each project has a new set of issue items, and corresponding fields which are custom built to support the project. Thus, as new projects are created and administrators start building request forms to support those projects, the administrators have to remember and search for each of those fields they wish to use. Generally, these searches are traditional keyword searching, which may yield limited results and which may not account for related items outside the searched keyword. Alternatively, an administrator may not immediately find a field to appropriately capture the needs for the intake interface and may elect to create a custom field. However, in some cases, creating custom fields may result in duplicates of existing fields created by other projects and/or by other administrators. This duplication consumes database space and, more importantly, makes it more difficult to harmonize fields within a knowledge base to extract valuable insights. For example, fields may include “DESCRIPTION.” “ISSUE.” “SUMMARY.” “NARRATIVE.” “EXPLANATION,” and the like, and they may be designed to capture the same things. However, due to the challenges of quickly finding the appropriate fields, an administrator may create a “PROBLEM DESCRIPTION” field when other fields were available. As a result of this interface, it may become time-consuming for administrators to create intake interfaces.

The systems and methods described herein relate to a service management system that automatically selects and sorts field items in an intake interface builder. The intake interface builder described herein may include a field region and a request editing region. The field region may include sorted field elements which are graphical representations of field items. Using the example interface, the field elements may be user selectable and may be dragged-and-dropped to the request editing region to quickly and efficiently build intake interfaces. In many cases, the field elements presented within the field region have been selected and sorted in accordance with a selection criteria.

In some embodiments, the selection criteria may be based on use history of the fields with respect to an enterprise, use history of the fields with respect to a project or type of project, and/or use history of the fields with respect to a particular user. In some cases, the use history reflects the use of the fields by users of the help desk or fields that are not null or contain values once the issues are created in the issue tracking system The intake interface builder may be configured to receive or track data that is based on user event logs generated through prior use of the service management system. Example user event logs may include a user's log history in a help desk, history of issues created in an issue tracking system, or user interactions in the same intake interface builder interface. In some cases, the user event logs (and thereby the recently used criteria) may be based both of the user's history as well as other users' history which may be associated with the user. For example, the group of users may be associated with the same project or same department. In some cases, the field elements are further sorted by a timestamp or date stamp so that the most recent fields used are on the top of the field region. In some cases, the field elements selected (e.g., based on the user event logs) may be further based on other criteria, such as alphabetical, field type, most popular, and the like.

In some cases, the selection criteria may be based on a semantic analysis of, at least, user input within the request editing region, such as title of the intake interface, description of the intake interface, and the like. A backend application may retrieve other existing intake interfaces (e.g., from the same project, from other projects, from the same department) which are semantically similar to the user input. Based on these retrieved intake interfaces, the backend application may extract the field items and display them as field elements. In some cases, the extracted field items may be further selected to display only field elements which have been used by the user or field elements that have been used at least a threshold number of times.

In other embodiments, the selection criteria may be based on a relationship of already-selected field elements in the request editing region. For example, a user selection of a field element (e.g., “HARDWARE ISSUE”) may be commonly used with “EMPLOYEE ID,” “HARDWARE TYPE,” and “WARNING SCREENSHOT.” Accordingly, the backend application may select those items commonly used together and display them as field elements in the field region. In other cases, the selection criteria may be based on project, user favorites, field types, and the like.

In other embodiments, the selection criteria is further refined by context data of the current session. For example, the selection criteria may be based on a project type of the current intake interface being currently defined. The selection criteria may also be based on recently created or recently modified project types and other activity performed in a current session or in a recent session with respect to the system. The selection criteria may also be based on a role, job description, or other attribute of the authenticated user. User attributes may be determined by obtaining a user profile for the authenticated user or by accessing other user-specific data on the system. In some cases, the selection criteria may include information obtained from other applications of the service management system accessed in the current session.

Regardless of the selection criteria, a user may quickly see the field elements within the field region and select them to be included in a request editing region. Upon user confirmation, an intake interface may be created that includes the selected field elements within the request editing region. In the same interface, a user may also change how the issue item is shown in the issue tracking system (e.g., via an “ISSUE VIEW” tab). At this interface, the field elements may be shown according to the same criteria as was used in the intake interface builder view. In some cases, the field elements may include other tags which indicate to the user that a particular field element has already been selected in the intake interface builder view. Thus, a user can quickly control what the request and the issue associated with that request includes (in terms of field items) within a single user interface. Moreover, the user may also view and edit the workflow. In some embodiments, upon including a field in the intake interface (e.g., a hidden field where the request is marked as “URGENT”), the workflow may change, allowing all issue items created under that intake interfaces to be treated under an expedited workflow.

These foregoing and other embodiments are discussed below with reference to. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanation only and should not be construed as limiting.

shows an example simplified system diagramincluding the service management systemdescribed herein. The systemis depicted as implemented in a client-service architecture; however, other implementations and communications architectures are possible. The systemmay include a set of host servers, which may be one or more virtual or physical computing resources (e.g., as a cloud platform). More generally, the service management systemcan be the infrastructure and services through which IT and/or enterprise service management services are provided.

The service management systemmay be communicatively coupled to one or more client devices from users,, and/or, which may be any suitable electronic device. Each client device from users-may be associated with a different user. The client device from users,,may each be operable to instantiate instances of a frontend application,,on their device. These frontend applications may be of any of the platforms and/or services of the service management system.

As discussed above, the service management systemcan support infrastructure for one or more backend applications, each of which may be associated with different software platforms that are part of or support the service management system. Users,,may access applications or services of the service management systemvia an authentication manager. The authentication managermay be a single centralized that can provide authentication as a service to each request before it is forwarded to other platforms or services. In some cases, the authentication managermay be authentication instances which are platform- or service-specific. More generally, the authentication managerauthenticates users (e.g., from client devices from users-) based on, for example, user credentials. In this example, the authentication managermay receive usernames, passwords, pins, passphrases, biometric data, or other user-identifying information. The user authentication data may be stored and/or tracked using tokens, cookies, or other data elements. Upon successful authentication by the authentication manager, the user may access the platforms and/or services of the service management system, such as a help desk serviceand the Issue Tracking Platform.

In the current example, the service management systempresents multiple different interfaces depending on the level of access and role of a particular authenticated user: a first interface provided by the help desk serviceproviding a issue reporting interface, a second interface provided by the form builder(e.g., leveraging the field selection service), which allows administrators to design, configure, and modify the issue reporting interface, and a third interface provided to an issue tracking platform, which allows users to process and monitor issues or tickets initiated by the help desk service.

In the example of an information technology environment, the help desk servicemay refer to an interface that can be used to collect information about a user's technical issue and create a ticket that is processed by an issue tracking platform. The help desk servicemay be operable to accept, classify, and define technical issues provided by users accessing a portal or interface provided by frontend applications,,operating on the client devices,,. In some cases the users operating the frontend applications,,are authenticated users. In some cases, the users are anonymous or manually enter identifying information through the help desk service. In some cases, the help desk servicemay also provide a knowledge base and reporting services. In some examples, the help desk servicemay also include community forums where users can ask and answer questions from other users in the community. An example of a help desk serviceinterface is shown in, and a workflow is included in. More generally, the help desk serviceis the starting point for documenting issues and organizing them according to enterprise policies.

The help desk servicemay be configured in any number of ways that allows the user to report issues, look for help regarding issues, and the like. In some embodiments, the help desk servicemay include department-specific or project-specific selections that help route the issue and resolve those issues in a streamlined fashion. In some cases, each department, project, or the like may be associated with different intake interfaces. As described herein, intake interfaces may refer to a series of screens and/or interface forms presented in accordance with a project defined by the form builder. These screens are presented to users in a help desk interface. Each intake interface may be tailored to each department, project, or the like to best capture useful information to resolve the issue. As explained above, information is captured via input items (representing fields) contained in each intake interface. The input items may include required and optional information. While hundreds if not thousands of field items may be available for different issues, displaying a limited number of fields as input items is important to avoid overwhelming users, to streamline issue creation, and to cabin the type of information used in the different requests.

In many cases, service agentsmay access the help desk serviceon behalf of users-. In other cases, users-may access the help desk serviceto report issues and the service agentsmay be available to resolve those issues once opened (e.g., via the issue tracking platform). For example, service level agreements (SLA) may be in place between a business and the customer (e.g., an enterprise). Service agentsmay access an authentication manager, which may be the same or different from authentication manager. Once authenticated, the service agentmay access a different frontend applicationfrom the frontend applications-described above. Via frontend application, the service agentmay access additional information not visible to users-. For example, the service agentmay access user profilesto obtain user data, such role of the user, one or more groups of which the user is a member, one or more projects that the user is associated with, identifying information, one or more tickets related to the user, and the like. In some cases, the user profilemay include user permission settings, user history, system settings, and other system profile data associated with the backend applications of the service management system.

In some embodiments, the service management systemmay include event log modules. The event log modulesmay track and/or store user actions, system events, or other data generated in accordance with activity performed by the system users. The event log modulemay include navigation events that are generated in response to user navigation to various pages, documents, user selection of certain issue items, user selection of field items, and the like. For example, the user event log modulesmay be used to determine recently-used fields in an intake interface builder. As another example, the event log modulemay also include logged activities from users (e.g., customers) at the help desk service, including fields filled out, and the like. In some examples, the event log modulemay also include fields used and/or filled in by a service agent in the issue tracking platform. In some examples, the event log modulemay also include fields commonly used by the administratorin the intake interface builder. Details of the various events may be accessed by a field selection servicefor selecting and sorting fields for displaying in issue intake builder.

A field selection serviceselects and sorts fields in a issue intake builder. An issue intake builder is a service which allows an administratorto build intake interfaces. The intake interfaces determine the number of fields, type of fields, required fields, and the like, to be displayed to users (e.g., users-or service agents) accessing the help desk serviceand to users accessing the issue tracking platform. More specifically, the field selection serviceis available to administratorsto facilitate building custom intake interfaces.

More specifically, an administratormay access the service management systemthrough a frontend applicationexecuting on a client device. The frontend applicationmay be a different application from non-administrator users, such as users-and service agent. For example, the frontend applicationof the administratormay include the intake interface builder which is supported by the field selection service. The frontend application-of users-, respectively, may include a more intuitive interface that allows users to quickly report an issue in the help desk service. An authentication manager, which may be different from authentication manager, may retrieve the administrator'suser credentials and authenticate the administrator. In some cases, the authentication managermay retrieve different user credentials or employ a higher-security authentication protocol to authenticate the user. For example, the authentication managermay require two-factor authentication.

Once authenticated, the administratormay access an issue intake builder, which instantiates an instance of the field selection service. The issue intake builder is part of the service management systeminterface. The issue intake builder allows administrators to create and edit intake interfaces. In many cases, for each project, new intake interfaces are needed to capture the needs of the project. As described herein, projects may refer to a broad category of portals within the help desk and within the issue tracking platform under which issue intake categories may be organized. For example, a project related to software development for a videogame may have different service requirements from a project related to hardware changes within an enterprise. Accordingly, a first request type may prompt the user to provide details on the version number of the software and a description of the issue. A second request, relating to hardware changes, may prompt the user to provide details on their current hardware and role within the organization. Generally, the issue intake builder allows administrators to determine which fields are visible in a frontend applicationgenerated by the help desk servicewhen filling out an issue item for a given project. The request form may also be used to determine what fields (and in what order) are visible in an issue tracking system. The fields visible in the issue tracking system may be the same fields or different fields from the fields presented in the intake interface at the help desk.

As explained above, the service management systemmay have hundreds, thousands, or hundreds of thousands of fields, depending on the size of the enterprise or the business managing the service management system on behalf of multiple enterprises. These field items may be stored in a database and leveraged by a form builder. The form buildermay be a service which allows users to configure forms for collecting and organizing data. The forms described herein may be deployed within any platform of the service management system.

The field selection servicemay leverage the user profiles, user event logs, and existing forms and field elements (e.g., from the form builderor databases associated with the form builder) to sort and display suggested fields to the administrator. For example, the field selection servicemay retrieve fields items that the administrator has recently used (e.g., while building a different intake interface), field items that other users associated with the administrator have used, field items associated with particular projects, and so on. The field selection servicemay select certain field items from the field items retrieved to display to the user and sort the selected field items in accordance with a criteria. In some embodiments, the criteria may take into account recently used items, type of field item, frequency of use, whether the field item is associated with a project where the intake interface is being created, field items frequently used together, and so on.

At the frontend application of the interface creation module, the sorted field items may be displayed in a field region. The field region may include the sorted field items displayed as field elements. Each field element may be selectable. For example, a user may drag or select the field element to be included in a request editing region. The request editing region may include selected field elements that form the intake interface. An administrator may change the order in which the field elements are displayed, the settings of each field, and other display preferences. For example, an administrator may edit whether fields are hidden in the help desk interface when a user opens a ticket. In some cases, hidden fields may be automatically populated by the help desk service. As another example, an administrator may elect certain fields to be visible and locked to users filling out a help ticket in the help desk interface. In other embodiments, the administrator may elect which fields are optional and required.

Regardless of the selections in the request editing regions, the field elements displayed in the field region are streamlined such that administrators can find relevant fields faster. In some cases, the field elements may be updated as the administrator selects certain fields and/or as other administrator-input is received. In some cases, the field selection serviceselects a predetermined number of fields, and, upon an administrator selecting all the fields, the service repopulates the field region with a new set of field elements sorted in accordance with a criteria. In this configuration, a user can scroll through limited options in batches.

Once an administrator finishes selecting fields in the request editing region, an intake interface is created. The intake interface may be available in the help desk and include the fields as configured in the request creator. In some cases, the request creator may also modify what fields are displayed in the issue tracking system and/or in other platforms within the service management system. As another example, the request creator may dictate the workflow that an issue takes when routed through the issue tracking system. For example, an intake interface may include a “PRIORITY” field. Upon selecting the “PRIORITY” field to default to “URGENT,” a workflow within the issue tracking platform may change to expedite resolution of the issue item. Workflow details are provided in.

These foregoing embodiments depicted inand the various alternatives thereof and variations thereto are presented, generally, for purposes of explanation, and to facilitate an understanding of various configurations and constructions of a system, such as described herein. However, it will be apparent to one skilled in the art that some of the specific details presented herein may not be required in order to practice a particular described embodiment, or an equivalent thereof.

Thus, it is understood that the foregoing and following descriptions of specific embodiments are presented for the limited purposes of illustration and description. These descriptions are not targeted to be exhaustive or to limit the disclosure to the precise forms recited herein. To the contrary, it will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.

shows an example workflowfor a user reporting an issue. Following authentication, a user (e.g., a service agent or a customer) may access the help desk portal. An example graphical user interface is presented in. As shown in, a home page of the help desk portalmay include sub-portals, which are defined by a series of interfaces defined in accordance with a project or intake category. Selecting an intake category may cause the portal to route a user to different features of the help desk. For example, the help desk portalmay include an ITSMwhere a user may seek IT-related assistance. Similarly, the help desk may include portalsfor different departments of an enterprise, including human resources, finances, and so on. The help desk portalmay also include a search barto facilitate finding of information, such as documents relating to a knowledge base.

Upon selecting a sub-portal, such as the ITSM portal, an interface for raising an issue is presented, as shown in. The interface may include multiple input items that corresponds to fields, such as a request type field, a requestor field, a summary field, and a description field. Upon selecting the request type field, the user may be presented with a menu of intake categories. This menu of intake categories may correspond with the menuof. As shown in, the menu of intake categories allows users to select a request that best fits their needs. For example, “FIX AN ACCOUNT PROBLEM.” “GET A GUEST WIFI ACCOUNT.” “GET IT HELP.” “NEW MOBILE DEVICE.” and “ONBOARD NEW EMPLOYEES” may each correspond to different requests. Each of these requests may correspond to intake interfaces-in.

Upon selection of an intake interface (e.g.,, or), a backend application may retrieve a form-that corresponds to the intake interface. Each of these forms may be created by an administrator via a request creator form interface. In some embodiments, each form is unique to the intake interface and includes input items that correspond to field elements from the request item builder and which is tailored to the user's issue category. An example form (e.g.,) is presented in.

As shown in, the form is tailored to relevant information relating to a “FIX AN ACCOUNT PROBLEM” issue. For example, the form may include a user field, a summary field, a description field, a department number field, an actual start, and an affected hardware field. As shown in the figure, certain fields may be required, such as the summary field, the user field, and the department number field. As explained above, each of these fields may be tailored to the particular problem.

Once a user (e.g., a customer user, a service agent) fills out and submits the form (e.g., via “SEND” button), the service management system may transmit the data to an issue tracking system, which generates an issue item based on the data from the form. As shown in, a service agent may have access to an issue tracking portal, which may be a graphical user interface of the issue tracking system (e.g., Issue Tracking Platform). At the issue tracking portal, a user may view the data input into the form from the help desk, view the status of the ticket, view/edit other information, and the like. An example issue tracking portal interface is presented in.

As shown in, the issue tracking portalmay display an issue item and relevant tracking information. For example, the data input in the formmay be displayed in a first display area. In some cases, users (e.g., agents, administrators) may edit these fields as more information is received. In some cases, the intake interfaces may include hidden fields. These hidden fields may be displayed to users in the first display area.

The issue tracking portalmay also gather other data (e.g., from user event logs or databases coupled to the issue tracking system), including similar requestsand activity. In many cases, enterprises use a service-level agreement (SLA), which specifies the process, timelines, and metrics by which services, such as IT, are provided. The issue tracking system may include issue item metric regions, such as regionsand, which may track metrics according to the SLA. For example, upon generating an issue item, the issue tracking system may automatically set a time for reply and completion that may correspond to the SLA. Similarly, regionmay include editable field items that may be used to resolve the issue. For example, an issue item may be assigned to particular service agents, the urgency of the request may be set, and the like. The issue tracking portalmay also include other fieldswhich may be used by service agents to track metrics, add labels, track time, and the like.

The issue tracking platform may process each of the issues or tickets in accordance with a workflow or series of predefined states that the issue must traverse in order to be resolved by the issue tracking platform. An example workflow from the time an issue time is created is presented in. In some embodiments, at the intake interface builder interface, a workflow can be defined contemporaneously with the intake interface and with the issue item view in an issue tracking platform. When an issue is created, a workflow for resolving the issue is generated (e.g., via a backend application of the service management portal, such as the issue tracking system). As a first step, the issue may be assignedto a service agent or other users. In some embodiments, the request type and/or other fields from the intake interface may determine the assigning step. For example, a group of users may be assigned to particular intake categories. As another example, a group of users may be assigned to a project where the particular request type can be used. As yet another example, a particular data input to a field (e.g., “AFFECTED HARDWARE”) may determine a user or a group of users to be assigned to the issue.

Once an issue item is assigned, the user or group of users assigned to the item may reviewthe issue. On review of the issue, the assigned users may resolvethe issue or may transferthe issue, as an example. Upon transferring, updated assignees may reviewthe issue again to ensure proper routing of the issue item. In some cases, the issue may be canceledor it may be linked to another issue for a combined resolution. In some cases, depending on the complexity and/or the type of request, the workflow may include additional steps or less steps. More generally, the request type may dictate the number of steps and workflow used for each of the issue items. Accordingly, building an intake interface may determine the fields displayed in the help desk, the fields visible in the issue tracking system, and the workflow associated with the issue item.

A sample issue intake builder is presented in. As described above, the issue intake builder allows administrators to quickly build forms for use in the help desk. These forms may be associated with particular projects, categories, and the like. The graphical user interfaceof the issue intake builder includes a field regionthat displays field suggestionswhich are tailored to each authenticated user account having administrator or similar permissions. While the graphical user interfaceis described as an independent graphical user interface, it may be part of the issue tracking system (e.g., Issue Tracking Platform), part of the help desk (e.g., help desk service), or part of other platforms that are part of the service management system (e.g., service management system).

To display field suggestions, a backend application may retrieve user event logs, user profiles, forms, and the like, from the service management system. These data items may include fields, data relating to recently-used fields, data relating to recently-created fields, and/or data relating to fields frequently used by the administrator or other users. The data items may also include the administrator's profile including assigned projects, and the like. The retrieved data items may be used to select fields predicted to be relevant to the administrator and sort them in accordance to a criteria.

In some cases, the selection criteria may be based on recently used fields by the administrator. For example, a backend application may retrieve the fields used with a predetermined time period and sort those fields in accordance with a time-related criteria. In this configuration, fields that are more relevant to a particular project can be easily found and each request type may be built in a more streamlined manner.

In another example, the criteria may be based on a usage criteria of the administrator and users related to the administrator in a common project. In this example, the backend application may leverage user event logs from users, such as other administrators or service agents, associated with the administrator configuring the intake interface. The association may be based on common projects, common departments, previous interactions, and the like. Based on the field use of the administrator and the users associated with the administrator, the service may select fields commonly or recently used by the administrators and other users with the common project. In this example, the selected fields to be displayed may be further sorted by fields recently used by the administrator followed by fields recently used by other users. As another example, the service may aggregate a usage frequency of the selected fields and display the fields according to a higher-use incidence criteria.