You are here:

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 vFire Core Workflow polling service must be running on the vFire Core server to execute any workflow-related activation.

Display the Request Details window in one of the following ways.

Select , and then Request. A submenu displays all of the available workflow templates. This may run to several levels.

Select the Request button in the banner . The Request from Workflow Template pop up window is displayed. Select a partition and Workflow Process for your request to display the list of available templates in the Templates browse list. Then select one of the templates and either double click or select New.

Select the arrow next to the Request button on the banner, if visible. Then select the template you want to use for your request from the drop down list. This may run to several levels if you have templates within workflow processes. Select the partition in which you want to create the request, if displayed.
The Request Details window is displayed. The window title will include the unique number that is automatically allocated to all types of request. Complete the details.

Some of the fields described below may not appear if the window has been configured through the 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 is displayed, 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
User	Specify the user by typing the name or using the Q/D button. 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.
Organization	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.
Location	Specify the user's location by typing the name or using the Q/D button. 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. vFire 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, vFire 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.
Description	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 vFire 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 or use the Q/D button to link configuration items to the current request. You can create and link a new CMDB item from within the Q/D menu if necessary. Multiple items can be linked through these fields. Linked CMDB items are also visible in the request tasks and approvals. SLAs can be invoked on a request based on linked CMDB items. If an SLA has not already been applied to a request through the SLA linked to the workflow template, SLAs will be applied if request details match the Workflow Selection Criteria specified for the SLA. If multiple matches are found, the system will use the higher priority criterion (defined in the Agreement Selection Priority in SLM administration) to determine which SLA to apply. Config Item and Request Type are the selected agreement selection priority with Request Type being higher than Config Item in the order. In this case, even if SLAs are found based on the Config Item, the SLA that matches the Request Type will be applied. Only if an SLA based on Request Type is not found, an SLA based on the Config Item will be applied. However, if Config Item is higher in the order, the SLA that matches the Config Item will be applied. If multiple configuration items are linked to the request, the SLA that matches the Config Item higher in the list in the CMDB Selection Priority will be applied. You can create an outage if availability is turned on for the linked CMDB item when you action the request by selecting the Create/Link Outages option. When you delete a CMDB item from a request and it has an outage, the outage on the CMDB will also be removed. Details of the associated outage will no longer display on the Outages window of the request. If the outage is set to occur at a later time, this will not affect availability statistics of the CMDB item. Otherwise, if the outage has been occurring at the time the CMDB item is removed from the request, only the actual downtime is recorded for the CMDB item.
Linked Services	Type the name or use the Q/D button to 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 vFire 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.

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.
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.

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.

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.
The Text 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.
You can create tasks and approvals used to implement a complete workflow in the dependency diagram.
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.
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 vFire 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 vFire 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.