Creating a Request

Analysts can create requests for any workflow process, provided they have access to both the workflow templates created for a process and the process itself.

Requests can only be created from workflow templates, and only for those processes that have templates defined.

Creating a request involves recording the details of the request for change that needs to be implemented. Once a request is created, you can forward it to another analyst, defer or complete it.

Before you start

You must have Create Request selected in the Requests tab of your Workflow Management security role.

You can only use the workflow templates, templates, and request screens to which you have access in the Req Screen Sets tab of your Workflow Management security role. If your security role does not have access to the request screen that has been used for the workflow template, the request will use the standard request screen.

The ASM Core Workflow polling service must be running on the ASM Core server to execute any workflow-related activation.

  1. The Request Details window appears. The window title will include the unique number that is automatically allocated to all types of request. Complete the details.
  2. Some of the fields described below may not appear if the window has been configured through the ASM Designer to capture different information. You may also see different or additional fields, depending on the template chosen.

    Request Title Specify a meaningful name for the request. If you add nothing, the system automatically completes the field with the default title Request Number xxxx
    Ref A system-generated reference number appears, which you can change according to the needs of your organization if required. For example, you can use this field to specify a project code for your organization

    Specify the user by typing the name in the User search field.

    If you want to search for a user using specific criteria, use the User explorer option. If you have already selected the user, clicking the User explorer option opens the Person Details window with details of the selected user.


    Specify the company to which the user belongs.

    This field is automatically populated if the user is linked to an organization.

    If you want to search for an organization using specific criteria, use the Organization explorer option. If you have already selected the organization, clicking the Organization explorer option opens the Organization Details window with details of the selected organization.


    Specify the user's location by typing the name in the Location search field

    This field is automatically populated if the user is linked to an location.

    If you want to search for a location using specific criteria, use the Location explorer option. If you have already selected the location, clicking the Location explorer option opens the Location Details window with details of the selected organization.

    Telephone Add the user's telephone number, if necessary
    Type Specify the classification (the type) of the request being created for change, for example, Normal Change - Minor.

    ASM Core supports up to three tiers for request types, as configured and specified by the system administrator. To select the request type, Click and navigate through the tiers to select the type you want.

    Priority Use the Priority drop-down list to select the required priority of the request. Note that the higher the priority, the more urgent the request.
    Risk Use the Risk drop-down list to specify the possible risks incurred if the request for change is not applied, or during its actual implementation.
    Target Date Specify the date and time by which the request should be completed.

    When you set a request target date, ASM Core checks the component tasks linked to the request and displays a warning if the dates appear to be inconsistent with that chosen in the Target Date field. This warning provides the option of extending the request target date to that displayed by the last task. If you click Yes on the warning window, the request target date is automatically updated.

    Imp Start Specify the start date and time of when the request will be implemented (that is, put into production)

    By default, the Imp Start field displays the target date on the request.

    Imp End Specify the end date and time of when the current request is completed or no longer implemented.

    By default, the Imp End field displays the target date on the request.


    Describe the request for change in as much detail as you wish. This information is particularly important if you need to forward the request to another analyst or group for completion.

    If HTML was selected as the default system format by the administrator, the Description field displays an HTML formatting toolbar. This Rich Text editor enables analysts to draw attention to critical information (for example, by using bold and/or italics).

    To enlarge the field, click full view.

    Actions & Solutions

    To categorize the type of action you are describing in the Actions & Solutions section, you can select the appropriate action description for the request in the Action Type drop-down list.

    You can also add information before saving, deferring or forwarding a request. Once the request is saved, the information in the Actions & Solutions field becomes a part of the request history.

    Self Service Portal

    If you want users to view the request’s action history on the Self Service Portal, select this checkbox. This is particularly useful for requests logged originally from the Portal.

    If Portal is not selected, users can view the request on the Portal but not its action history. Whether Portal is selected or not by default on the Request Details window depends on whether Request History Private was selected on the Workflow Management Settings window. To open the request history, click View History.

    Action Type Specify the action type from the drop-down list.
    Linked CIs

    Type the name to search for and link configuration items to the current request.

    Multiple items can be linked through these fields. Linked CMDB items are also visible in the request tasks and approvals.

    Linked Services Type the name to search for and link services to the current request.
    Security If security profiles are enabled and you have access to more than one security profile on your person record, you can restrict access to the actions and solutions, objects, emails and notes of each request logged in ASM Core. To allow only the analysts linked to a particular security profile (for example, Management) to view the Actions & Solutions field, select the security profile in the Security drop-down list. Analysts without access to that particular security profile cannot view the aforementioned request information.

  3. All tasks and approvals linked to the current request are displayed in the Tasks tab on the Request Details window. This tab enables you to see the current status of all tasks within the request, including whether it is authorized, currently active or has been completed. To view the details of a specific task or approval, double click the corresponding row, or select the task/approval and then click Review to view it or Open to update it.
  4. The Budgets tab enables you to view the current status of the request regarding the allocated and accumulated cost. It displays a list of all actionable tasks linked to the request, along with the current analyst who owns the task, and for each task, a summary of the budgeted v actual time, expenses and cost incurred. Budgeted times and costs are displayed are red. Actual times and costs are displayed in black. Total costs (budgeted and actual) are displayed for each task in pink. The total costs for the request are displayed at the bottom of the table.
  5. Cost is the sum of analyst time multiplied by their charge rate, for all analysts who have actioned the task. All budgeted and actual figures show the total time, expense and cost for all analysts on the task, not just the analyst listed in the Task Header column. The last row on the browse table displays the total budgeted and actual time, expense and cost for the request. This is the sum of the budgeted and actual values for each actionable task.

  6. The Dates tab enables you to view the current status of the request regarding the implementation dates of the tasks linked to the request. It displays a list of all tasks linked to the request, along with the analyst who currently owns the task.

    A negative value in the Late (Start) Date field indicates that the current task started before the allocated start date and time. A negative value in the Late (End) field indicated that it ended before the planned end date/time.

  7. The tab displays a list of all tasks linked to the request followed by the descriptive information relating to each task. This is particularly useful to see an outline of all the tasks, without having to open each task individually to review the details.
  8. You can create tasks and approvals used to implement a complete workflow in the dependency diagram.
  9. The workflow template on which the request is based may already include the appropriate tasks and approvals. However, the dependency diagram and components of the workflow can still be updated at the level of the request.

  10. Next, you can action the request by:
  • authorizing it if necessary, to release any unauthorized tasks and approvals for action
  • Some requests may be pre-authorized at the level of the workflow template on which they are based

  • forwarding it internally to another analyst for further action or resolution
  • You can forward multiple requests at the same time.

  • forwarding all tasks and approvals to the appropriate analysts
  • deferring or saving it to work on it later
  • closing it if it is completed.
  • Requests can be actioned from the explorer pane, Favorites menu, or the buttons on the toolbar.

  • Actions on a request, including the date and time when the request was logged, are automatically recorded in the request history.

When an analyst logs a request, if they have manager rights, they are set as the request manager of that request. If not, the request manager will be the authorizer if the template is pre-authorized, or the template creator if the template is not pre-authorized.

Ownership of a request is not transferred to the other analyst or group until they open the Request Details window and click Take Action. When a member of a group takes action on a request, the request is removed from the other group members’ Requests Outstanding window.

If a request has been opened by an analyst for editing:

  • It cannot be closed by way of a Closure Task if the request has been opened by another analyst for editing. However, the request will be automatically closed by the ASM Core polling service when the Request Details window is closed and available for updating.
  • If a user wishes to approve a linked User Approval Task from the Self Service Portal, they can still approve the task. A warning message will be displayed. However, if the task has been set to update the request status and the request has been opened by another analyst, the request cannot be updated.
  • Initialization rules for Conditional Branching and Activation tasks will not be triggered until the request window is closed. This is because these tasks may need to update details on the request, which is not possible if the request is being actioned by an analyst. The task will thus be delayed until the request is free to be updated once more.

Toolbar Buttons on the Request Details Window

From the Request Details window, you can do the following using the toolbar buttons:

Hide the explorer pane
Copy the contents of the Description field
Paste contents from your clipboard into the Description field
Attach a file
Check the spelling in the details
View the request history
View the dependency diagram - a diagramatic representation of the workflow
View as a gantt chart