Global requests management

🤦 🤦 🤦 Combodo's customers only 😎 😎 😎

Some situations, like the arrival of a new employee or the departure of a sub-contractor, requires multiple actions to be performed by multiple teams. With a manual process, there is some drawbacks, such as:

• An action can be forgotten to be requested,
• An action can be required while prerequisite aren't performed yet.
• Requiring the different actions independently force to reenter the same information multiple times.

This extension address the drawbacks listed above, by automating the creation of the multiple requests.

User experience: On the iTop User Portal,

• The requester chooses in a catalogue of Global Demands, the one corresponding to his need, for example “Arrival of a new employee”,
• Then he is prompted from global information related to this situation, in our case “employee name” and “arrival date”
• All the actions required in this situation are listed, in our case it could be “Ordering a new PC”, “Ordering a company access badge”, “Ordering a mobile phone”,…
• The requester can uncheck some of the proposed actions.
• Then a single page prompt for all additional parameters needed for performing the selected actions.
• When the requester submit his Global Demand, it automatically creates as many User Requests as there are actions requested in the Global Demand.
• Then the requester can follow each User Request, as if he had created them separately.
• His Global Demand will be automatically closed when all its User Request will be.

In details:

• Groups several service subcategories under a new type of ticket called Global User Request,
• At creation of the global request, automatically creates the different user requests associated to the service subcategories attached to the global user request,
• Handles all the user requests templates at once, if any,
• Provides a 2 level approval scheme for the global requests, and the user requests
• Set the individual user requests on hold until the global request is approved,
• Prioritize the processing of the user requests,
• Automatically close the global demand when all user requests are closed,
• Applied SLAs are specific to each User Request, depending on the associated Service. This is the major difference brought by this extension, if compared to Catalog of Procedure
• Definition of global request types is managed trough a specific typology element,
• There are no limitation in the number of global request types that can be created,
• A given type of request belongs to one of the 3 following codes: arrival of an employee, departure of an employee, generic case, each of them defining a set of specific attributes for the global request,
• Different global request types with the same code may be created, linked to a different set of service subcategories.

• Requires Approval Process Automation, Customized request forms and Dispatch User Request to a team,
• As a result, it is not compatible with the iTop Essential product.
• Global Request can only be created in a Portal, not in the console.
• A given service subcategory can only be linked to one direct parent subcategory of higher priority. When a subcategory has a parent, if it is selected, its parent subcategory is automatically included, even if not part of the “Global Demand Type”, assuming it is visible by the user.

• During Global Request creation, you can't add an attachment to a Global Request nor to any depending User Request. You can do it later, by updating the User Request.

Requires at least iTop 2.4.0.

Use the Standard installation process for this extension.

Ticket::

public function DBUpdate()
{
        $this->WaitForPriorityRequest();
        if (count($this->ListChanges()) > 0 ) {
              parent::DBUpdate();
        }
        $this->ProceedPendingPriority();
}

The following settings are available to configure the module:

The following standard settings might be of interest when setting up the approval feature:

• email_asynchronous
• email_transport

In the end-user portal, creation of a global request is possible through the GlobalRequestBrick. One instance of the brick is added to the standard portal by default with the ID new-global-request. The brick is based on the CreateBrick so it has the same parameters (see here) plus some specific ones:

As a prerequisite, iTop administrator needs to define the types of Global Requests that portal users can create. For that purpose, he'll need to create new Global Request Types from the Typology configuration menu available under Data administration.

(*) Technically Service Subcategories are not mandatory, but a Global Demand Type without any is useless, as no Global Demand of this type can be ordered in the portal in that case.

To improve the efficiency of Global Demand, some service subcategories need to be performed before others, as they are dependent. This dependency can now be specified thanks to a parenthood attribute.

The different user requests created under the same global request, use this service subcategory hierarchy for processing parent first, and starting the children only when the parent is resolved. Example if, for instance, the “New DNS name” subcategory has the “New IP Address” as a parent, then, the user request for the “new IP address” will need to be resolved before the user request for the “new DNS name” can be processed.

The Parent Service Subcategory attribute can of course be left empty.

A service subcategory can be used for different Global Request Types.

This class of tickets is, as well, modified by the Global Request extension.

A few attributes are modified or added…:

… and the life cycle has been adjusted accordingly:

The 3 new status have been inserted at the beginning of the standard life cycle of a User Request.

• Waiting for Global Request approval: Pending the approval of its parent Global Request,
• Pending priority request (GR): Pending the resolution of a UR with higher priority,
• Cancelled … if the Global Request has not been approved.

A specific approval process has been created for the Global Requests. Like the standard Extended Approval Scheme this one relies on the Base Approval module.

Please, refer to the Approval process automation documentation if required.

A Global Request can only be created from the portal. For that purpose, the extension brings 2 additional bricks to the standard portal:

• One to handle the creation process
• Another one to list and update the ongoing requests

At creation time, the user is required to select a Global Request type among the ones available.

Once selected, he fills the different attributes related to the request and selects the service subcategories to be created and processed as part of this global demand.

When the user submits the request, iTop will check first that no customized request form (request template) needs to be filled. If this is the case, then a page is displayed where the user can fill its choices.

Pressing the “Submit” button will create the global request and all associated (unitary) user requests.

The newly created global request will then follow its life cycle.

During the life cycle of a global request, the requester can update its public log in order to provide further information to the support agent in charge of the request. He may as well change the list of contacts and add an attachment. The global request is automatically closed when all individual requests are closed.

Once created, the individual user requests will follow their own life cycle. However, a user request linked to a parent user request of higher priority will wait in the status 'pending priority' that the parent ticket is resolved before following its own cycle (approval process, dispatch, assignment…).

Global Requests are managed from the console where a dedicated menu group, including an overview, is added by the extension:

The search and open menus, below the Overview, handle global requests, regardless their final class…

… where the Shortcuts menus look after each individual final class of global requests.

The “waiting for approval” menu lists all global requests that are pending for an approval. Should that be necessary, an administrator (or any profile that have the appropriate rights) may bypass the approval process for a request, from that menu, and that way, move the global request directly in the state “work in progress”.

Q: When should I use “Global request management” instead of “Catalog of procedures”?
A: Both offer to automatically create sub-objects with dependencies, based on a predefined template, but with “Global request management” you can:

• pick and choose the sub-objects to create (by selecting the service-subcategories) during Global Request creation
• define complex sub-objects, thanks to “Customized request forms”
• track SLA on each sub-object
• manage approval on the sub-object level

Q: How Global Request extension work if one of my “Global Request Type” Service/Service Subcategory is not link to my Customer Contract ?
A:

1. If your Service Subcategory has no Parent service subcategory, this Service Subcategory won't be proposed in the Service subcategory of your Global Request. The regarding UserRequest won't be created.
2. If your Service Subcategory has a Parent service subcategory which is linked to your Customer Contract, the regarding UserRequest will be created if you choose The Parent service subcategory.

Q: What happen if a manually suppress a User Request part of a Global Demand?
A: If another User Request within the Global Demand was waiting for the resolution of the delete one, then it will wait forever, and can only be deleted also.

Q: Who can create Global Request in the Portal?
A: Any Portal user can create a Global request in the Portal by default. This can be changed by customizing the Portal.

Q: Can I create a Global Request in the Console?
A: No. Also there are means to create a Global Request object in the console, it will not propose any service sub-categories and won't create any associated User requests, so it should not be done.

Q: Can I clone a Global Request in the Console with an object copier action?
A: No. For similar reasons as for the above question.

Q: Can I csv import Global Requests?
A: No. For similar reasons as for the above question.

Q: What happen if during the GRType creation, we put a circular reference in the service subcategory dependency?
A: Such situation is not checked. To prevent it, you can change the type of the field parent_servicesubcategory_id from ExternalKey into HierarchicalKey.

Q: Creation of Global Demand in the portal fails with error: “Twig content not allowed in this context!”
A: This is due to a security fix brought by iTop 2.7.6. In order to fix this just add this config parameter

Configuration file

$MyModuleSettings = array(
  'itop-portal' => array(
    'enable_formmanager_content_check' => false,
  )

In 2.7.7, this bug is fixed, and this param is removed

Q: How can I choose/force Impact and/or Urgency for UserRequest automatically created by a Global Request?
A: UserRequest are created with default parameters for Impact and Urgency. If you want to force Impact and/or Urgency, you need to add two items in globalrequest-to-unitaryrequest <action_rules> in your Portal Design. These new values will be set for all UserRequests created by a Global Request.

itop-design / module_designs

<module_design id="itop-portal" _delta="must_exist">
      <action_rules>
        <action_rule id="globalrequest-to-unitaryrequest" _delta="redefine">
          <source_class>GlobalRequest</source_class>
          <presets>
            <preset id="1">set(origin, portal)</preset>
            <preset id="2">set(impact, 1)</preset>
            <preset id="3">set(urgency, 1)</preset>
          </presets>
        </action_rule>
      </action_rules>
</module_design>

Q: Can I propose a mean to my Portal users, to create Global Requests or User Request in a single menu?
A: With iTop 2.7, there is an option, with a BrowseBrick, displaying GRType and below Service sub-category. The top level would create a GlobalRequest, while the level below would create a simple UserRequest. Note that this cannot include Incident, will maybe propose the same service subcategory multiple times and will not propose service subcategories which would not be part of a GRType.

Q: Is there any dependency between the Global Request & associated UserRequest caselogs?
A: Out of the box, no. You may put some using standard customization in the ITSM Designer if you have PHP developer privilege.

Q: Can I use the CreationBrick for creating Global Request?
A: No, you have to use the Brick brought by the extension.