One of the most common system governance items for Project Server Admins is the handling of the projects that have been checked out for too long. I have discussed the reasons why projects need to be checked in timely, here.

There could be some projects that are checked out for a period of time, for legitimate reasons, but more often than not, it is the forgetful project manager, who forgot to check their project in.
In an environment that spans thousands of users, the number of these projects that remain checked out too long, just keeps increasing. It is a common practice for the admins to take care of the force check-ins manually, but what if we could automate the process? How cool would be, if there were some kind of workflow that checked for these checked-out projects, evaluated if they were checked out for too long,  and then checked them in automatically?

Thankfully, Nintexhas some cool functions that allow use to automate this process. So, let’s look at building a workflow that will help us in this process.

Step 1: Build the workflow

  • Start by navigating to Nintex Workflow 2013 >> Create a Site Workflow
  • Build the workflow with each of the steps as described. Each of the “Configuration” links will give you the configuration for each of the actions.
We start with the Query Project Server, to get a list of ALL project UIDs, and store them into a collection variable.

Next, start a collection operation using the For Each operation, so that we can look at each Project GUID that we collected in the previous step.

For each of the Project UID, Query Project Server, to query for projects that are checked out. We will get the values “Checked Out date”, “Checked Out By”, and “Project Owner”

Set a variable, to calculate the difference between the current date and the date the project was checked out. This should be based on the policy of your organization.

Once we get the data for each project, we would want to handle only the projects that have been checked out for more time than dictated by the organizational policy. To do that, we use the Run If action, and specify the conditions as shown in the configuration.

For the projects that are identified, as the offenders, you can decide what you want to do. You can send the Project Owner a notification to let them know that the project is being checked in because it has exceeded the amount of time that a project can remain checked out. Alternatively, you could also add a reminder to check the projects in, and then pause for some more time to let them check in the project. I am not handling this scenario in my workflow example here.

Now comes the real meat of the process, the actual Force Check-In.  Nintex allows us to interact with the PSI web Services which allow us to force check-in the project without manually having to do it.
We will use the Call Web Service action, and call the QueueCheckin web method, to check the project in. Configure it as shown the configuration image.
That’s pretty much it, on the building of the workflow. Now we will need to schedule the workflow, so that the process is fully automated.

Step 2: Schedule the Site Workflow

  •  Now navigate to Nintex Workflow 2013 >> Schedule Site Workflows and click on Add Schedule

  • Fill out the details and schedule your workflow, per your requirement. Click Save.

That’s it. Now the Site workflow will check for checked out projects with whatever frequency you have scheduled it for, and send reminders, and then force check-in the projects.
The full workflow file can be downloaded here: Force Check-In Projects
As mentioned before, you can enhance this workflow to add more details like a reminder service, a report generated AFTER the projects have been checked in and so on… the possibilities are limitless.

Whew! One less thing the project server admin has to worry about!