Tag: Workflows

Administration With PowerShell

Robert Everatt / / Administration, Powershell, SharePoint 2010

SharePoint workflows’ aren’t as complex as I would like them. without Visual Studio, the options that you are given are quite limited, and not very flexible when you want to do something a little more complicated. The action that I wished to carry out was to edit a users properties from the workflow, however the workflow can only read user properties, and not write to them.

After searching the internet for an answer, I saw someone talking about Windows PowerShell scripts.

PowerShell in SharePoint 2010 is an administrative tool that carries out its work in a command line. This allows the administrator to carry out commands’ and is great for repetitive process’. One of the features that intrigues me the most is the ability to easily create PowerShell scripts, they can also be initiated by workflows which makes the task of editing User properties very simple, if the PowerShell can grab data from the workflow then the Powershell uses this to find the relative data and edit it accordingly.

Unfortunately I still don’t know much about this as it is only usable on SharePoint 2010, which we do not yet have. More info when I get it.

RE

High-Privilege Workflows in SharePoint 2010

Robert Everatt / / Office 365, SharePoint 2010, Workflows

For the last week now, Michael and I have been struggling with a very persistent workflow issue. An approval workflow that we have created, works fine when it’s started by an administrator, however when it started by a regular user, then the approval process won’t work. The workflow is activated with the permissions’ of the user that started it, not the permissions of the approver or the author. It isn’t currently an issue for the work we’re doing, but it will need to be fixed for use in a real world environment. Googling the problem didn’t seem to help, there were too many vague “fixes”, that required complicated multiple workflows that never seemed to work. There didn’t seam to be a solution to this problem anywhere on the internet. However, I then remembered that someone gave me a large SharePoint 2010 book as a “congratulations for getting the job”, so I decided to see if I could find a solution in there. The solution showed itself almost immediately.

The answer is: High-Privilege Workflows. I found this solution to be extremely easy carry out, and it solved our workflow problems 100%. A high-privilege workflow runs with the permissions’ of the person who created the workflow. While editing the workflow, you simply click in the area just below the first step, go to the “insert” section of the ribbon bar and click “Impersonation Step”. This adds a new step into the workflow that carries out the actions within it using the permissions of the workflow author.

I find it embarrassing that the solution was so simple, however I thought I might write a post about it,  incase any others users were coming across the same issues.

 

workflow

RE

Holiday Workflow Continued

Robert Everatt / / Limitations, Office 365, Workflows

Work on the holiday approval workflow has continued over this last week. We have been adding more and more actions into it, just to see what we can accomplish. We described our workflow to Dave in out monthly review meeting, and he metnioned other features that should be implemented.

Previously, the workflow calculated how many day’s the user’s holiday is, taking into account half days, and input this into a calendar. To make this workflow more intelligent, and useful, I set up a list that would contain the name and department of each member of staff, with a number of how many days of holiday they have left. Before editing the workflow, I created a custom data view of the list, showing only the members of the Online Services team. This feature was requested by Dave as he wanted to see how many holiday days each member of his team had, and creating a list for this data appeared to be one of the only ways to implement it. This method isn’t entirely desirable, as each time a member is added to the Sharepoint site, they also need to be added into the “Holidays Remaining” list. Another issue that has been raised is that, the “Days remaining” field will need resetting every year, and as of yet we do not yet know a way of resetting every feild at once with a single workflow.

We then incorporated the workflow with the list, getting it to subtract the holiday from the “Days remaining” field. We have found with this particular workflow could easily spiral out of control, there will always be something else to add to improve it and get it to do more. This will most likely be the same for a lot workflows, you just have to find a good stopping point.

RE

Our first workflow

Robert Everatt / / Limitations, Office 365, Workflows

It’s been a few weeks since our last blog post. In those few weeks Michael and I have been looking heavily into workflows, as that is probably one of the most important features of SharePoint 2010 for us, and has the possibility to benefit the University greatly, if used correctly.

Following on from creating a reusable workflow to deal with the annual leave request process, which was successful, we wanted to move forward. This involved associating the workflow to a list. After completing this you may have seen in a previous post, that we were running into a lot of issues since the change. We contacted Microsoft concerning this around a month ago, and although the problem no longer appears to be present, the Microsoft support team did next to nothing about it except repeat the same questions. The workflow situation seamed to resolve itself and we are now able to fully utilise workflows.

Now that the workflow is working we were able to re-create the paper based holiday system. We created a simple form that would ask the user when the holiday starts and ends and, if this was a single day, whether it was a half day. Once submitted the workflow was set to start automatically. This would send the initiator a confirmation email with a summary of their request. Next the initiators manager would be found and the request would then be sent to this person. In the instance where a manager can not be found, the request will be emailed to a nominated person, so that the task can be re-assigned to the appropriate person. The next step occurs once the manager has approved or rejected the request. The next stage will send out an email to the initiator detailing whether the request has been approved or not. If it has not been approved the request will also be deleted from the list. If the request is approved, the details are transferred into the corporate calendar.

We are now looking to test what else workflows could manage for us.

RE & MB

Workflows [Updated]

Michael Bratley / / Capabilities, Features, Office 365

Over the last few days I have been looking at Workflows in the Enterprise Edition environment, after they were very limited in the Small Business Edition. I started by creating a reusable workflow, that can be applied to almost any list or document library. This workflow would allow users to request annual leave, the workflow would then get their line manager to approve or deny the request. This worked very well, and did what I expected it to. After accomplishing this Rob and I decided to add more functionality, which would add the leave (if approved) to the corporate calendar. At this point I discovered that the workflow would need to be associated with a specific list to enable it to obtain all the fields within the Annual Leave list. This time I recreated the workflow as a list workflow and selected the list to associate it with. I could now access the required fields to add the approved request to the corporate calendar. However upon testing the workflow, it stopped at a certain point and returned an error. Below is the workflow that has been created, and the sections in red appear to be causing the problem, this process does start though as an email is sent to the initiator to say this.

I have been trying to find a solution to the problem, but so far have been unsuccessful. I have discovered though, that the workflow may need to be split in to two. When the workflow is initiated, it runs under the permissions of that user, which will not likely have permission to approve items. I will be looking at this soon too.

Update:
After submitting a service request to Microsoft, I have this morning (17/10/2011) been contacted by a representative, who has taken me through some troubleshooting. Throughout this he took screenshots to enable the process to be recreated, to try and identify the problem. A solution is expected on Wednesday.

Update 2:
The representative from Microsoft has since been in touch to inform us that he is still working on the problem.  A solution is expected any day now.