Content Includes:


The Workflow pages and Get Next button are based on work in the XpertOnline Provider (XOP) utility program. No matter if you have Administrator or User rights, the Workflow options automate the process of finding and managing outstanding work in the form of RMCR or non-RMCR (Infile) requests that need your manual attention. Instead of sorting through the numerous requests that already exist in XOP, updaters/processors (users setup with User rights) and managers (users setup with Administrator rights) can use the Workflow tab and the Get Next button to view and open outstanding requests ordered by oldest service date/time stamp and priority level.  

 

 

 

Managers can use the Workflow Assignments menu option to view current workflow assignments and assign/reassign outstanding requests to updaters/processors.   

 


Three related features in the XpertOnline Provider program that automate the process of finding requests that need work are the Get Next button, the Workflow tab, and the Workflow Assignments menu option. These features are defined as follows:

  • Get Next (button)—Users and Administrators alike can use this button and associated checkboxes to have XOP get the next request that requires manual work. This assigns the opened item to the user that clicked the Get Next button.
  • Workflow (tab)—This tab shows Users and Administrators those requests that have been assigned to them. When theWorkflowtab is blank, use theGet Nextbutton to find the next request that requires manual work.
  • Workflow Assignments (option under File menu)—Only Administrators have this menu option available to them. When a user with Administrator rights selects the File | Workflow Assignments menu option, they can view lists of all requests that are currently unassigned, of all requests that are currently assigned to a user, and can reassign currently-assigned requests to other users.

 

A Note on User Rights in XOP

There are two different defined user rights for employees in the Provider’s office actively using XOP. Users can be setup with Administrator rights or User rights, and users with different rights can do different things with the Workflow and associated screens. The person with Administrator rights has the ability to assign work to a person with User rights. The person with User rights will then find the pending request that has been assigned to them and work on it per the service requests.

 

A person with Administrator rights can assign a request that needs manual attention to someone else in their office. They can also view lists of which updater/processor has been assigned to which request, lists of requests that have not been assigned to updaters, and can reassign previously assigned requests to other updaters. Administrators can also perform any work that a User can.

 

A person with User rights can view requests that have been assigned to them on the Workflow tab; they can also search for the next request that needs manual attention via the Get Next button and Take Ownership of any unassigned requests. Once the person with User rights has found work to do, they can then open the request and begin working in it. If an updater’s Workflow tab is blank, they can search for requests that need work by using the Get Next button. This document details these processes.


Get Next Button

After a successful login to the XOP program, updaters/processors (people assigned with User rights) will begin looking for a place to start their work. To eliminate the time that it takes to locate work, updaters/processors should view the area below the menu options, but above the tabs. This area contains a Get Next button, checkboxes, and a Service Team field, all of which come together to automate the process of finding work.  

 

Important Note—the Get Next button should be used after the updater/processor’s Workflow tab is empty (blank), indicating that there is no remaining work that is assigned to them.  The Get Next button opens and assigns the next outstanding request to them.

 

 

The main difference between XOP’s Get Next/Workflow options and XpertOnline.net’s Get Next/Workflow options is that XOP searches for the next outstanding request instead of the next outstanding service within a request. The Get Next button will only open entire RMCR or entire non-RMCR (Infile) requests in XOP, whereas XpertOnline.net searches, finds, and opens the next trade line or line item to work on.  Therefore, users need to keep in mind that when they take ownership of a single service, the entire request will become assigned to them.  If the user cannot take ownership of a single service on a request, the request is assigned to another user in their office.

 

As in XpertOnline.net, XOP defines an RMCR as any request whose product has the RMCR service enabled on it. Non-RMCR requests will be in a status of Updating but will not have the RMCR service aligned to the product.

 

To the right of the Get Next button are the checkboxes that can be configured to open certain items. By default, the RMCR checkbox will be checked, as will the Include Gold Items and the Include Silver Items checkboxes. If an updater/processor clicks the Get Next button and takes the defaults here, XOP will search through all existing requests for the updater’s provider number and open the RMCR request that has the oldest service date/time stamp on it and that’s in an Updating status.  It will open Gold priority RMCRs first; if there are none, it will then open Silver priority RMCRs; if there are neither Gold nor Silver priority items, the RMCR request with the oldest service date/time stamp that is in an Updating status but is not prioritized as either Gold or Silver (as setup on the product) will open so that the updater can begin working on it.

 

Updaters can choose to search for and open the next Infile (non-RMCR) request by checking the non-RMCR checkbox; they can also choose to not include Gold and/or Silver items by unchecking the corresponding checkboxes.


Get Next Search Criteria 

When you click the Get Next button, XOP searches through all requests ordered by all Subscribers/Clients with the following prerequisites to find work for you, the updater/processor:

  1. The RMCR or non-RMCR request must be outstanding, meaning that the request must be in a status of Updating.
  2. The outstanding RMCR or non-RMCR request that opens will have a service date/time stamp older than any other service date/time stamp. Here, note that the service date/time stamp is the time at which the first service was applied to the request—this is different than the Ordered Date of the request. The service date/time stamp will appear in the Requested column.
  3. The outstanding RMCR or non-RMCR request that has the oldest service date/time stamp must be unassigned, meaning that no one has taken ownership of or been assigned to the request.
  4. The outstanding, unassigned RMCR or non-RMCR request that has the oldest service date/time stamp must not be currently open and locked by another user.

 

These four criteria are taken into account “behind-the-scenes” after you select on the Get Next button, meaning that no matter if you select to open an RMCR or a non-RMCR, if you choose to include or exclude Gold/Silver priority items, or if you want to filter by Service Team name, these four criteria above will always be taken into account. Essentially, as an updater/processor, you simply need to understand that when you click the Get Next button, the request that you should work on next will be found and opened automatically for you.

 

Configuring the Get Next Button

Once you know that when you click the Get Next button, a request that needs manual attention will be found, opened, and assigned to you, you need to understand that you have the option to configure exactly what type of request will open.

 

Updaters will see that there are four checkboxes and a Service Team field to the right of the Get Next button. This is where any configurations are set.  

The first set of checkboxes determines the type of request that will open.

  • RMCR—this is the default. When checked, the Get Next button will open a request ordered with the RMCR service.
  • Non-RMCR—when checked, the Get Next button will open a request that does not have an outstanding RMCR service on it. The type of request that opens is an Infile or a completed RMCR request that needs manual work by an updater/processor.

 

The second set of checkboxes determines the priority level of the request that will open. For your information, Gold is the highest priority, Silver is the medium priority, and Standard is the normal priority. Priority levels are added at the time a product is created or when a message (user service request) is posted to a line item or a request.

  • Include Gold Items—this is checked by default. When checked, XOP will open a request (either RMCR or non-RMCR) in an Updating status that has a Gold priority level on the product and that has the oldest service date/time stamp. When unchecked, XOP will ignore all requests that have a Gold priority level on the product.
  • Include Silver Items—this is checked by default. When checked, XOP will open a request (either RMCR or non-RMCR) in an Updating status that has a Silver priority level on the product and that has the oldest service date/time stamp.  When unchecked, XOP will ignore all requests that have a Silver priority level on the product.  
  • When both the Include Gold Items and Include Silver Items checkboxes are checked, as is the default, XOP will search for the request (either RMCR or non-RMCR) with the oldest service date/time stamp that is in an Updating status and that has a Gold priority. If no Gold priority requests exist, it will move on to Silver priority requests. If neither Gold nor Silver priority requests exist, XOP will open the request with the oldest service date/time stamp that is in an Updating status that has no priority level (Standard).
  • When neither the Include Gold Items nor the Include Silver Items checkboxes are checked, XOP will open a request (either RMCR or non-RMCR) with the oldest service date/time stamp that is in a status of Updating that has a Standard (normal) priority level.

 

The third section is a Service Team field that allows you to filter the requests by Service Team. Here, the default is ALL, meaning that all service teams—including Subscribers/Client that have no Service Team assigned to them (blank)—will be searched through. If a you type in a Service Team name and click the Get Next button, only those outstanding requests that match the value in the Service Team field will be searched through. If you click the drop down arrow for the Service Team field, you can select the (Blank) option, which limits the requests that are searched through to those that have not been assigned a Service Team.

 

Once you have configured the Get Next button to open either an RMCR or a non-RMCR, to include or exclude Gold/Silver priority items, and typed in a Service Team, click the Get Next button to have XOP open the next request that needs manual work based on the four criteria.  When the request opens, your user name will automatically be assigned to this request so that other employees in your office know that you are working on this request.


Take Ownership 

If you open a request without using the Get Next button and wish to assign the request to yourself so that other updaters/processors in your office know that you are working on this request, when the Request Detail page opens and you are viewing the Instructions/Notes tab, right click in the upper portion of this page and choose Take Ownership.  This assigns your name to the Assigned field for this request.

 


If you right click on the Request Detail page to take ownership of a request and the Take Ownership option is grayed out, someone already has been assigned to this request and you should not make any manual modifications to this request without the permission of the owner of this request or your Manager/Administrator.



Another way for updaters/processors to take ownership of an entire request is to post a message to a single account from the Detail tab of the Accounts screen. When a message is posted to an account, the updater/processor will see a Take Ownership checkbox in the lower left of this pop-up screen. If the entire request is unassigned, the user can check this checkbox to have the entire request assigned to them. If the entire request is already assigned, the checkbox will be grayed out and unavailable.



Another Workflow-related option on this right-click menu is the Assign Request To… menu option. When selected, a user with Administrator rights who has a request open in the Request Detail page can assign this request to a user listed in the subsequent drop down list, shown here.

Administrators can also reassign requests using this method.

 

Overall, requests can be assigned ownership in three ways:

  1. Administrators can assign an updater (user with User rights) to each of these requests—either by the Workflow Assignments screen or by choosing the Assign Request To… option shown above.
  2. An updater/processor can open a request, right click in the header section of the Request Detail page, and choose the Take Ownership menu option.
  3. When posting a message to an account, users can check the Take Ownership checkbox, if it is available, to assign the entire request to themselves.
  4. Clicking the Get Next button automatically assigns that user (either an Administrator or a User) to the request.

 

When a user (either an Administrator or a User) is assigned to—or takes ownership of—a request, the user’s name will print in the Updater field on the final printout. However, other users in your office can still open a request and make changes to it even if it is already assigned to another user. If this happens, the other user’s name will appear in the Edit Log tab of the Request Detail page.  Remember, once a request has been assigned to a user, or a user takes ownership of a request, the Get Next option will ignore it.

 

Workflow Tab

As an updater/processor (person with User rights) working in XOP, your first item of business is to find the request that needs work. This can be done easily by logging into XOP and viewing the Workflow tab. This tab contains a list of all outstanding requests that have been assigned to you. The list of outstanding requests is ordered by descending priority level, meaning that the first request listed on the Workflow tab is your highest priority and that this is where you should start your work. The request listed below this is your second highest priority; the third request is your third priority level, and so on until the list of outstanding requests ends.

 

 

XOP takes into account the priority level of entire requests and the service date/time stamp on requests. The priority level of a request is set when a product is created or when a message is posted to a request—this priority level is listed in the first column on the Workflow tab. The service date/time stamp is the date and time that an outstanding service was applied to a request—this date/time stamp is listed in the Requested column. 

 

If no priority levels (Gold or Silver) are aligned to any product, the Priority column will read Standard, and the Workflow tab will be ordered so that a request in an Updating status with the oldest value in the Requested column will be listed at the top. This indicates that this request has been in the system longer than any other request that needs manual work and that it should be worked on first.

 

If products have been setup with priority levels (Gold or Silver priority), the oldest Gold priority items will sort to the top, followed by the oldest Silver priority items, and followed by Standard (or normal) priority items sorted by the oldest service date/time stamp.  

 

Updaters will also notice an RMCR column here as well—this column shows the you whether this request has the RMCR service enabled on it, designating the request as an RMCR request. When the RMCR column is blank, the request is a non-RMCR (Infile) request.

 

The Workflow tab is ordered this way so that you can view only those requests that either you have taken ownership of, or that were assigned to you by a user with Administrator rights. It is also ordered this way so that you know where to start your work on requests and can work down through the prioritized requests.

 

Once you find a request to begin working on, you can double click it to open it into the Request Detail page, or you can right click and choose the Open Request option. This opens the request into the main Request Detail page—into the Instructions/Notes tab—so that you can begin working on it.

 

When a request opens into the main Request Detail tab, you can view the Services tab and double click on any service to open the account that needs work.

Workflow Assignments

For users with Administrator rights only

 

The Workflow Assignments option is found beneath the File menu option.  If you are not logged into XOP with Administrator rights, the Workflow Assignments menu option will not appear beneath the File menu. This is a valuable tool for Administrators to ensure that requests are worked up, completed, and sent back to the originating Subscriber/Client by updaters/processors (persons assigned with User rights in your office) in a timely manner.

 

When you select the File | Workflow Assignments menu option, the Workflow Assignments screen opens. You will then be prompted with a Workflow Assignments/Service Team prompt. From this prompt, users can select if they only want to view requests assigned to a certain Service Team or not. Typing in the name of a Service Team will bring up only those requests that have been assigned to that Service Team. If you leave this field as is, a list of all outstanding requests that need manual work will display (note that at any time you can choose to filter the list of requests by Service Team name). Remember—use of Service Teams is entirely optional. 


These requests are separated out between two tabs: the Unassigned tab and the Assigned tab. The Unassigned tab contains requests that can be assigned to updaters/processors; the Assigned tab contains already-assigned requests. By default, the Unassigned tab opens first.

 

 

You can filter the Workflow Assignments screen by Service Team at any time by typing in a Service Team name into the Filter by Service Team: field. If you would like to do this, once you type in the Service Team name, click the Apply Filter button or press the <Enter> button on your keyboard for this filter to take effect.

 

To the right of the Apply Filter button is a series of checkboxes. These checkboxes are filters as well—they limit what the list of outstanding requests contains.  

  • RMCRs—this is the default. When you first view the Workflow Assignments screen, the list of outstanding requests will only contain RMCR requests. Remember—RMCR requests are those requests that were ordered with the RMCR service on the product.
  • Non-RMCRs—check this checkbox to only display outstanding requests that were not ordered with the RMCR service on the product or that have the RMCR service completed.
  • Both—check this checkbox to display both outstanding RMCR and non-RMCR requests.

 

The Service Team filter and the RMCR, non-RMCR, and Both filters can be used on either the Unassigned or the Assigned tab.


Assign To Button and User List

The lower right section of the Workflow Assignments screen contains an Assign To button and a table that lists all users for your Provider company that currently have access to and log into XOP.

 

Use the Assign To button to either assign unassigned requests to an updater or to reassign already assigned requests to another updater. Make sure that the request you would like to assign/reassign is highlighted, and that the user you would like to assign to the request is highlighted, and click the Assign To button.

 

Below the Assign To button is a table containing a User column and a Count column. The User column includes all users (Administrators and Users alike) setup under your Provider company that can be assigned to a request. The Count column lists how many requests are currently assigned to each listed user.

 

 

Unassigned Tab 

This tab lists all outstanding requests that have not been assigned to an updater. Assignment of a request is vital to the life span of a request—when a request is assigned to a specific updater, it is ultimately that updater/processor’s responsibility to complete the request and print it back to the originating Subscriber/Client.

 

 

You can determine that a request has not been assigned by viewing the Assigned To field—if this field is blank, no updater has been assigned to this request.

 

To assign an updater to a request, find the Assign To button and the User list in the lower right corner of the Workflow Assignments screen. The list of users here includes all users (Administrators and Users alike) that currently can login to XOP and work on requests for the Provider’s company. Follow these quick steps to assign a request to a user in this list:

  1. Make sure that the request you would like to assign is highlighted in the list of unassigned requests. Single-click on a request to highlight it.
  2. Highlight the name of the user in the User list that you would like to assign to this request. Single-click on a user name to highlight it.
  3. Click the Assign To button.
  4. The assignment process saves automatically when you click the Assign To button.

 

Administrators will notice that, once they click the Assign To button, the name of the user they selected from the User list will populate into the Assigned To column of the Unassigned tab.

 

Assigned Tab

This tab lists all outstanding requests that have been assigned to a user. Administrators can use this tab to reassign requests to other users, to see which user has taken ownership of or been assigned to which request, and to check on the work progress of a request.

 

 

Reassigning a request is done just as assigning a request is done.  Follow these steps:

  1. Make sure that the request you would like to reassign is highlighted in the list of assigned requests. Single-click on a request to highlight it.
  2. Highlight the name of the user that you would like to reassign this request to.  Single-click on a user name to highlight it.
  3. Click the Assign To button.
  4. The reassignment process saves automatically when you click the Assign To button.

 

Look in the Assigned To column to see which user has been reassigned to this request. 

 

To check the work progress of a request, either double-click it or right-click and choose the Open Request option. When the request opens into the Request Detail page, go to the Services tab—this tab contains all outstanding service requests for this request. Administrators can then highlight each service and view the status of each on the right hand side of the Services tab to see how the work is coming along on any request.  You can also double click on a service listing in the Services tab to open the account detail page that requires the manual work.

 

Requests in a Done Status

When an updater/processor or an Administrator is finished making manual changes to a request, they will need to do two things to make sure that the request is statused to Done and that the originating Subscriber/Client receives the updated request:

  1. Make sure that all services on the request are set to a Done status.
  2. Print the request back to the originating Subscriber/Client.

 

When all services are marked as Done and the request is printed back to the Subscriber/Client, the entire request will be statused to Done.   Note that the entire request will not be statused to Done until it has been printed back to the originating Subscriber/Client.

 

To print the request back to the Subscriber/Client, from the main Request Detail page, click the Print button, set the desired Outputs, AddOns, and Destinations, and then click the Send to Mailbox button.

 

If an RMCR request is in a status of Done, and then the client posts another supplement (user service request, or, Message) to the request, effectively taking the request out of a Done status and mark it with a status of Updating, the entire request will become Unassigned so that any user can begin completing the user service request. This is based on the idea that only one updater/processor can work on a single request.  

 

Users (updaters/processors) and Administrators alike should now have the ability to take advantage of the associated Workflow options in the XOP utility program.