So I am running a project internally at the moment about moving away from a vended product to a capability in Office 365 / SharePoint Online using out of the box functionality as much as possible (cost saving exercise) – The Oil & Gas industry is hitting hard times if you haven’t seen commodity prices lately!
Anyway, this interim / temporary solution requires me to send an email to an external user.
With the SharePoint 2010 workflow engine, you could do this with a standard SharePoint Designer workflow.
In SharePoint 2013 they essentially deprecated the SharePoint 2010 workflow engine and introduced a new Azure based version.
This newer workflow engine requires the user that you send an email to an authenticated user with Active Directory / Azure Active Directory. This causes me an issue for my temporary solution in SharePoint Online!
Can Nintex Help?
I initially thought… perhaps Nintex Workflow for Office 365 Workflow can help?
Alas, it is based on the SP2013 Workflow engine, so no luck there…
(To be fair, you can’t really blame Nintex for supporting the current standard… I would do the same)
What are my options?
1. Add the external users to Azure AD – Not really an option in this case right now
2. Create a 2010 platform workflow with a single step – Email User. Call this workflow from the 2013 workflow and hope it stays supported – For this temporary solution, this may work but we all know how temporary often becomes permanent.
3. Create my own code / action to call a web service and send the email – This would work but for this temporary no code solution, it feels overkill. A good backup however, if the solution turns permanent.
4. Find a 3rd party product that can add actions. PlumSail has a package: https://plumsail.com/workflow-actions-pack/. $400 per year. – This is also a good option but there is of course this gotcha!
There isn’t going to be a SharePoint Designer 2016.
SharePoint Designer 2013 however still works.
Now that I have my newly installed SP2016 On-Premise environment and I can confirm that this is still currently available when you connect SharePoint Designer 2013 to a SP2016 On-Premise server.
I can also confirm that as of the time of writing, it is also still available in SharePoint Online.
So for this “temporary” project, this is likely the way we will go, knowing full well, it might go away at some point.
Stay tuned for more posts about SharePoint 2016 as I answer my own questions about the real business issues I face.
I was recently asked to help out a client who was having problems with standard Out Of the Box Approval workflow.
We checked the Farm and isolated the issue to one specific site collection, all other site collections were fine.
To resolve this we opened the site collection in SPD, open the All files section drilled into the _catalogs/wfpub folder, the folder for the Approval workflow was present but for some reason the wfconfig.xml file had been modified from the site definition (Shown by blue I symbol), once this file had been reset to the site definition workflows were working again.
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.