Tag Archive for Request Management

Request Management Solution (Beta) – One solution, many applications, much easier

About a year ago I wrote an article about “work request management” that drills into 4 scenarios and compares and contrasts them – Customer Examples of Work Request Management apps for SharePoint.  Lots of type of requests should be managed.  Examples are: Trouble tickets (IT), Requests for proposal (BD), Capital Purchase Requests (Finance), HR Staffing (HR), Contract Reviews (Legal), Material Storage (Manufacturing), Demo Requests (Sales) and Marketing Campaign Requests (Marketing) …

These types of Requests are important to respond to.  They generate work or use capital or other resources and should be managed.  Requests and the associated work need visibility, tracking, reporting, a structured and automated way of getting them approved and tracking the work.  They are a core way that work gets initiated and done across your workplace.  The problem is that often, the types of requests that should be managed end up instead being driven through ad hoc activity, mainly email.  This adds costs and risks to the organization.  Multiple the cost/risk of one scenario times the number of scenarios and it is a big cost with a lot of risk.

CorasWorks is very well suited for request management applications.  Over the last year, we’ve seen more and more CorasWorks-based applications created to address all sorts of types of request management needs.  The ROI on these apps is very good – however…

The practical challenge for organizations is that there are so many different scenarios. They are architecturally quite similar but differ in the details.  And, the details matter to the end customer.  While the end result is quite good using CorasWorks, it takes a bit of time and some knowledge to configure CorasWorks for each specific application and to modify it when things change.  Compared to other options, we have a good general solution.  But, we thought that with a bit of focus we could make it even easier, more approachable, more scalable, and, more cost-effective for you to meet the business needs.

So, we decided to create a “vanilla” Request Management solution.  This solution, now in Beta, leverages the new v11.3 feature set to make it much easier to crank out purpose-specific request management apps.  It is the “vanilla” version.  You use the solution and the new onboard features to create your flavor of it to meet the specific business needs. Thus, the value proposition is not that you get just one application, but, you get a one solution that allows you address a whole lot of applications.

The Demo – 6 minutes

Below is a video that shows the new Request Management solution.  It walks you through the “vanilla” solution and then shows you some of the new features to make configuration a snap such as the Application Designer, Process Designer, Business Rule Sets, and Stage-based Request Details (shown below).

Request Management Video image


The Solution Beta

The solution is now in Beta.  We are working with customers that want to try it out and have specific application scenarios in mind that they want to address.  If you are interested, send an email to info@corasworks.net or contact your account representative.


Customer Examples of Work Request Management apps for SharePoint

Over the last month, I’ve worked with a number of customers that are deploying applications for various scenarios of work request management.  This category of application is very common for all organizations and works great with CorasWorks on SharePoint.  It leverages the collaborative nature of a SharePoint environment and the work management feature set of CorasWorks.  The key design principal is to recognize that they are fundamentally cross-functional processes.  In this article, I’ll look at 4 different customer scenarios.  I’ll talk about what is common amongst them and how they differ.  I believe that any SharePoint Service Delivery Management team should make this category of app a staple of their offerings.  Once you get the core design pattern, you’ll find lots of applications for it.

Basic Work Request Management app

There are six core elements that are common to work request apps as follows:

  • They are an app, meaning there is a core site dedicated to this purpose vs. it being a feature added to a team site.
  • A requestor fills in a form to kick off a request.
  • The requestor can see, track, and engage with assigned “workers” on their requests.
  • Workers and Managers do various things (automated CorasWorks actions and forms) to respond to and complete the request.
  • Requestors and others are notified of activities and/or collaborated with.
  • You have reporting on the activity.

Customers Scenarios

Here are the 4 customer scenarios:.

Materials Storage for Pharmaceutical Manufacturing

This application is for requests to store chemicals (materials) within a manufacturing group.  People make their requests and others work the requests noting how long items are stored and where. Requestors are notified of the work and they get pinged when their storage expiration date is approaching.

IT Requests for SharePoint Work and Help Desk Tickets for Health Agency

This customer uses a couple of different WRM apps for IT to support the organization.  One allows users to log the requests for the SharePoint team for new sites, changes to sites, or new apps.  The SharePoint team then manages these requests.  The other is a WRM-based “Help Desk” app where users enter tickets and Help Desk folks work them.

Employee Requests of HR for Pharmaceutical

This customer is using WRM to enable employee across the enterprise to make requests of HR.  In this case, they created three request workstreams.  Each has a slightly different set of work management activities.  From the user perspective they are able to see the different requests in a single display from wherever they work.

HR Staffing Requests for Federal Contractor

An important process for many Federal Contractors is making requests of HR to find or recruit people to work on contracts.  In this case, a business development (BD) person working on a new proposal/task order makes requests of HR to staff specific positions.  The requests are related to specific Proposals/Task Orders.  However, HR manages all of the requests centrally.


All of the above follow the same basic design as described above.  People make requests.  People work on the requests.  There is back and forth.  The requests are closed out.  There is reporting.

The interesting part is that these are four very different “applications”.  In many organizations, they would presume that they would be looking to go out and buy or build completely different applications.  However, with CorasWorks on SharePoint each of these uses the same basic framework.  Thus, armed with one basic design you can now fill many different needs and save lots of time an money in the process.

Further, when you build them, the things that you will primarily change are also common:

  • The core data (fields) of the “work request” list are different.
  • The request form is different.
  • The worker roles are specific to the process.
  • The app navigation is different.
  • The displays and most importantly the worker/manager actions, work forms, and notifications are different.
  • Reports are different.

With CorasWorks, each of the above is easily modified using our wizards.  So, you have a common app design and you know the common things that you will be changing to accommodate the specific needs of the app.  If you look at it like an assembly line, you are all set to deliver.

Key Deployment Differences of the Apps

While the four apps have many core commonalities, there are differences in the overall deployment approach across the SharePoint environment.  This is important because work request management is fundamentally a cross-functional collaborative process.  Thus, where people go to engage, whether requestor, worker, or manager, can be different based upon the scenario.


In the Materials Storage app, all of the different users work in a single app site.  Requestors go there to make their requests.  Workers go there to do their work.  Managers go there to manage.  This makes it easier to create the app and is the way you would typically start.  However, it is not really a best practice given the ability to distribute functionality using CorasWorks.


In the IT Request app, the Requestors don’t go into the app app site to make requests.  They are able to be elsewhere across the SharePoint environment and enter their requests from their and see their requests and interact.  This makes it more convenient for the users.  Generally, you start by building the app as an All-in-one and then just distribute the displays.

Many Projects to Work Management Team (Hub and Spoke)

The HR Staffing app is a bit different.  In this specific scenario, you have many Proposal/Task Order sites (or could be project sites).  A team is working on these projects.  They enter their requests from the site.  However, the HR Work Request site is central – all of the requests feed into the one app.  HR is then able to manage it all in one place and interact with the requestors via their project sites.  This ends up as a Hub and Spoke deployment.


The Employee request design is different also.  In this case, there is a self-service page in the enterprise portal.  Users go to this one place and enter and see their requests across the three types.  The requests are funneled into the three different workstreams managed by HR.  HR is also able to work on them via a single display.

Getting You Spun Up for Work Request Management

The work request management category of app is a staple of SharePoint environments that have gone past basic site centric content sharing.  We often work with customers to train up their SDM teams to deliver this category of app.  We have a standard set of templatized apps and training to help get you going quickly.  Email support@corasworks.net for more information.