In this first section we will start creating our SharePoint Designer 2013 workflow. Our focus here is the “Call HTTP Web Service” action. We will be using and Ebay web service for this example. The response from the web service is in JSON (See image below). The “Call HTTP Web Service” workflow action would be useless without the new “Dictionary” workflow action.
In this section we will be taking the workflow a bit further.
1. We will extract the “Title” and “DealURL” data from the JSON response.
2. We will then create and entry in the WebServiceList for each node in our JSON response ( 7 in total )
Following on from yesterdays post regarding problems with getting into the CA site, today we got on with the job of looking at Web Analytics, and the reports that we can provide to end users.
So we checked the Web Analytics reports and could see good graphs like the ones below, very nice.
Just the sort of thing you could hand to a client.
So the next stage was to get the Schedule Web Analytics Reports workflow running and send the reports to a test user for analysis, this is when the fun started, no matter what we did the workflow simply refused to work, all we were getting was “An error has occurred in” and no reports, nothing in the ULS logs, nothing in the Event Viewer and nothing of any help in the Workflow History list, really handy, we knew that ‘normal’ workflows such as Approval worked fine on this system, so it was a bit baffling.
After a few(more) hours of head scratching I decided to try the Schedule Web Analytics Alerts workflow instead, which still failed, but at least gave out a more helpful error.
Of course it turned out that our test account didn’t have a mailbox (duh!), so we used a different account (with a mailbox) and the Schedule Web Analytics Reports worked fine
But it really annoyed me that 2 workflows related to the same area in SharePoint have clearly been developed by different teams in Microsoft and both show different failure messages for the same event.
We go the reports out finally, and they are just straight Excel exports, so we might not even use them, another fun packed day working with SharePoint !
Just a quick blog to go over which features should be enabled for Approval tasks in SharePoint Designer 2010 Workflows.
Project Server – PWA. Workflow being created within a Project Site.
Features enabled at the site collection (PWA):
Features enabled at the site (PWA):
- Features enabled at the site (Project Site):
However, we were getting the following error appear when trying to use the “Start Approval Workflow” action:
Cannot insert this action. To use task process actions, the Office SharePoint Server Standard Site features must be enabled for this site by an administrator.
Interesting error message given that the Standard features were enabled at both the Site Collection and Site level.
On further inspection, it turns out (rather obviously) that the Workflow feature needs to be enabled at the Site Collection level.
It caught us out for a little while, but a quick Google and thanks to this MSDN Forum post, we got the result we needed:
Hopefully, this post helps somebody out.
New with InfoPath 2010 is a People Picker control, this acts like the People Picker in SharePoint and allows you to choose contacts from AD.
I was using this control recently and wanted to promote the chosen person value to a list when the form is submitted, to my surprise I found that the submitted value was just a text value, not a presence aware name, so had none of the rich integration that OCS or Lync offers.
To get around this drawback I had to write a small workflow that fired when the form was submitted.
The workflow read the list value into a variable and then wrote it back to another column in the same list, but was key was to make the return field data type an Email Address.
Now we have a presence aware Name value.
Most SharePoint 2010 solutions will have some form of workflow associated with them.
Workflows written in SharePoint designer can be powerful, but tricky to troubleshoot if they do not work correctly.
Some workflows will complete but not perform as expected, and some will simply fail with the ever helpful An error has occurred in <Workflow Name> written to the history list.
To help us out with this is the Log to History List core action in our workflow designer Action List.
This allows us to write a message to the workflow history, and as such we could write back the value of a workflow parameter or variable that we can check on.
To illustrate this I have written a one step workflow with one Variable and one Parameter, the workflow has an Initiation Form that allows a user to select a colour.
We set the variable varColour to be the value of the colour the user selected which is stored in the parameter ParamColour , on the second line we use the Log to History List to output the value of varColour to the workflow history.
This is what it looks like, firstly we choose a colour from the Initiation Form
The workflow processes and completes, when we check the History list we can see that our message and the value of varColour have been recorded in the Workflow History list
Normally the Workflow History list is hidden from the browser, but you can change this setting in SharePoint Designer.
A common thing I do for most clients is to create a unique alphanumeric ID that is consistent in length with pre-filled zeros.
Risk list alphanumeric ID example:
However, as has been documented many times (link); you cannot use the ID column of a list in a calculated column. To get over this issue I use a simple SharePoint Designer workflow to copy the ID value to another column (Unique Reference) and then base my calculation on the Unique Reference column.
Step One: Create a common site column for use across the Site Collection
- Column Name: Unique Reference
- Column Type: Single Line Of Text
Step Two: Create a calculated column for the alphanumeric ID
- Column Name: Risk ID
- Column Type: Calculated Column
- Formula: =”RSK” & TEXT([Unique Reference], “0000″)
NB: The TEXT function will prefill the ID with zeros
- Step Three: Add the Unique Reference and Risk ID column to your List or Content Type
Step Four: Create the SharePoint Designer Workflow
- Create a list or content type (SP2010 only) workflow
- Workflow should fire on Creation only (disable Manual and Edit)
- Use the following steps:
- Publish the workflow (list workflow)
- Assign the workflow to the content type (if you have created a redistributable workflow in SPD 2010) and assign the content type to the list (content type workflow)
Step Five: Hide the Unique Reference column in the list / content type
- This will stop the Unique Reference column from showing to the end user.
NB: You must hide the Unique Reference column after you have created and published the workflow otherwise it will not appear in SharePoint Designer
You list items will now have a unique alpha numeric ID
NB: Please remember that automatic workflows will not fire if you are logged in as the farm account (link)
This post shows you how to utilise a little known workflow action in SharePoint Designer 2010, which allows a workflow to fire off an email to a user’s manager.
Note that your AD hierarchy needs to be correct for this to work.
Step 1 – Create a Custom List (Absence Log)
Here I created a basic custom list, adding the columns you see below;
- Member of Staff (Person or Group)
- Date of Absence (Date and Time)
- Reason for Absence (Single Line of Text)
- Estimated Duration (Choice)
- Line Manager (Person or Group)
Step 2 – Create List Workflow (SharePoint Designer 2010)
Now open up SharePoint Designer 2010, choose ‘Workflow’ on the left hand navigation and then create a new ‘List Workflow’ – selecting the Absence list.
- Create a New Action –> LOOKUP MANAGER OF A USER