Copying Data Between SharePoint Lists

Why would you need to do this you ask? You just never know. For a real world example where this came in handy, see the following post: Hiding List Data from Unauthorised Users

In SharePoint Designer, on the site you list resides in, click on 'workflows' and choose list you want to copy from from the 'list workflow'  drop down list. Once you have named the workflow saved it, click on the 'edit workflow' option, and choose 'Copy List Item' from the list of available actions.

Choose the option to copy the current item to the list you want to copy to, as per the screenshot below.

Next, go back to the settings page for that workflow and tick the 'start workflow automatically when an item is created' box.

Next save a publish your workflow.

Test the workflow by creating a new item in your first list. Next, go to your second list and check that the item has been copied across to this list.

Hiding List Data From Unauthorised Sharepoint Users

We recently implemented a Share Point list for managing IT Purchase requests, and one of the requirements was, understandably, that the person requesting the item could not see all the purchasing information (supplier, quotes etc.) that the office administrator needed to add to the list.

Although you can create different views of a form for submitting and editing a list item, there's no out of the box option for restricting different views of a form or list to different users or groups.
The solution we implemented, which works pretty well, was to create two separate lists and copy the information between the two.

So, in this scenario, we wanted to enable staff to request a quote for additional IT equipment not supplied as part of our standard service offerings (let's say for instance, a 40inch monitor for a meeting room, or a high-end MacBook). Once the quote had been obtained, and the details where entered into the list, an approval workflow would kick in, sending an email to the relevant budget holder and an appropriate person in IT to approve or reject the purchase, and then email the requestor and the person responsible for IT purchasing of the outcome.

End to End Process:

• The person filling out the form fill in the details of their request and adds a budget holder and recipient for whatever item they are requesting, or marks themselves as the budget holder and/or recipient. Alternatively, if you want force any request to be authorised by someone's manager, you can use the 'find manager' action within the SharePoint Designer workflow to kick of the approval process with them. This depends on your Active Directory being up to date, and also assumes that a budget holder or senior member of staff will never request something for themselves.
• The recipient and budget holder details are automatically populated with the details of the person filling out the form (see Anne Stenberg's incredibly helpful blog here for instructions on doing this). These fields are hidden from view, unless the person filling out the form chooses selects ‘no’ from the ‘Are you the intended recipient?’ drop down and/or ‘no’ form the ‘Are you authorised to make purchases for your team or department?’ drop down.
• The recipient is directed to a holding page here once they have completed the form. They also get an email confirming their submission.
• An email is then generated to the IT Administrator asking them to get a quote from a supplier. The workflow pauses until the ‘supplier’ field has been filled in.
• Once the quote details have been filled in, an email is sent to the budget holder name on the form.
• If the budget holder rejects the quote, the process stops there. If the budget holder approves the quote, an email is sent to the Head of IT for approval. If the Head of IT rejects the quote, an email is sent to the budget holder informing them of this, and the process stops there.
• If the someone within the IT Approvers group approves the quote, an email is sent the budget holder, and another to the IT Administrator telling them to raise a purchase order.

The Setup:

• Create a list that people will submit their requests to.
• Create a second list in the same site, with field names and types exactly matching the first list. To this list you can add the additional field that you want to hide from people submitting to the first list.
• Customise your forms in InfoPath.
• Create a workflow on the the first list to copy the details across to the second list, and email the person submitting their request to let them know it's been received and is being actioned.
• Create an approval workflow with the budget holder and the IT Approvers group.
• Update the list view in SharePoint Designer.

This workflow resides in a document library that is not trusted

There's a first time for everything, and after extensive testing on an list requiring approval from within Outlook, one of our testers got the following message: 'This workflow resides in a document library that is not trusted'. We tried all the obvious things, adding the site to the 'Trusted Sites' section in IE, checking browser settings/ versions etc. and just couldn't get the bottom of it. The fact that the tester was working on a pretty non standard PC build for our organisation ( Windows 8, Office 2013, IE10) turned out to be a little bit of a red herring. The solution that got us there in the end was to out the full URL into trusted sites ( i.e: http://sitename.domain.com) instead of just that site URL (i.e. http://sitename.com) .

Various forums had unresolved threads on this topic, so thought it would be worth putting out there. You just never know.

Ending a Sharepoint Workflow on First Rejection:

I' m just going to come right out and say it: SharePoint's out the box approval process leaves a lot to be desired. There, let the chips fall wherever the hell they will.
They're not customisable, and the emails they send out to approvers and the person kicking off a workflow are vague and obscure at best, and completely meaningless to anyone not familiar with SharePoint.
Luckily, SharePoint designer provides a pretty user friendly interface creating workflows that can be customised to meet most of your requirements. For a primer on pimping a basic SharePoint workflow, it's pretty difficult to beat Bobby Chang's post on nothingbutsharepoint.com
All very good, the only problem I had after setting up my first workflow following Bobby's method, was that I wanted any person reviewing the item for approval to be able to reject it, and  for that to end the worflow, rather than requiring everyone to complete the workflow before its status moved from 'in progress' to 'rejected'.
To achieve this, add an action ahead of the approvals process (using the set 'workflow variable' option from the actions dropdown' list)  to set 'cancelonrejection' variable to 'yes', as in the screenshot below