Web Dev Share Etc.

Definiamo un campo di tipo Date Time per immagazzinare il giorno per l’invio dell’alert, ad es “AlertDate” Definire da SharePoint Designer, un Workflow, in creazione/modifica, denominato “Set Alert Date” che aggiorna il campo AlertDate con la scadenza desiderata. Ad es, si vuole essere avvisati 7 giorni prima della scadenza (EndDate)? Impostiamo AlerDate = EndDate – 8 giorni (poi vediamo perché 8 e non 7) Definire un secondo Workflow, senza nessuna spunta (no manuale, no automatico) così non verrà visto da nessuno, se non l’admin Chiamiamolo “Send Alert For End Date” Il Worflow invia una mail ai destinatari da avvisare. Eventualmente, possiamo fare in modo, dopo l'invio, di impostare AlertDate = AlertDate+1 (se AlertDate < EndDate), così da inviare mail anche nei giorni successivi fino alla scadenza. Ora, navigare sulla lista/library interessata dall’alert ed entrare in List Settings > Information Management Policy. Definiamo una Policy per l’Expira...

In September 2012, I've opened a thread in SharePoint Dev Center Forum about an issue on globally reusable Workflow in SharePoint Foundation 2010. You can find thread here:  http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomizationprevious/thread/66cf91e8-9d38-4573-948c-071e66763ba3/ Today, I received an answer from Microsoft! Yes: there's an issue and they give KB to solve!  http://support.microsoft.com/kb/2846543/en-gb :-)

Per poter filtrare i documenti o gli item di una lista in base allo stato del workflow, possiamo creare una nuova vista e configurare il filtro utilizzando la colonna [Stato flusso di lavoro] . Ma se proviamo ad inserire come filtro, ad es., "Approved" o "Rejected", non otteniamo risultati. Lo Stato del Workflow, infatti, viene memorizzato come un valore numerico! I valori sono i seguenti: Not Started - 0 Failed on Start - 1 In Progress - 2 Error Occurred - 3 Canceled - 4 (manualmente) Completed - 5 Failed on Start (retrying) - 6 Error Occurred (retrying) - 7 Canceled - 15 (da workflow) Approved - 16 Rejected - 17 L'impostazione corretta del filtro sarà quindi come l'immagine seguente: Fare attenzione ai valori per Canceled!  Sono diventato matto, ma se la Cancellazione è stata eseguita automaticamente dal Workflow, usare il valore 15, se invece il Workflow è stato interrotto manualmente dall'amministratore (ad es perché in err...

In order to filter documents or items in a list by status of the workflow, we can create a new view and set the filter using the column [Workflow Status]. But if we try to insert as a filter "Approved" or "Rejected", we do not get results. The Workflow Status is stored as a numerical value! The values ​​are as follows: Not Started - 0 Failed on Start - 1 In Progress - 2 Error Occurred - 3 Canceled - 4 (manually) Completed - 5 Failed on Start (retrying) - 6 Error Occurred (retrying) - 7 Canceled - 15 (from workflow) Approved - 16 Rejected - 17 The correct setting of the filter will then be like the following image: Pay attention to the values ​​for Canceled! If the cancellation is done automatically by the Workflow, use the value 15, but if the Workflow is stopped manually by the administrator (eg because of error), then you need to use a value of 4!

I defined a Globally Reusable WF for a custom Content Type in root site, with a custom form with InfoPath. I defined a sub site with a list using the global WF template created for its Content Type. Everything works without problems. Now I need to change the WF (both in form and in the process). BUT.. If I edit only the form with InfoPath and then I publish the form, I see correctly the new form in WF on subsites. If I change the WF logic too (any actions) and publish WF (in root site), changes are not perceived by WF on subsites. WF on subsite is updated only if, on subsite, I open WF to change (from browser) and save it. I expect that you can update all WF in subsite using template in root site, without having to reopen and resave each WF in each subsite. I don't understand if it's a bad configuration or a issue on Globally Reusable WF. (I opened question in Technet Forum, here ) UPDATE: Sometimes, I update a WF (form and logic) and logic has been correctly pub...

I create a new Workflow Template (globally reusable) in root site and I associate it to a List in a Site Template. But I need to update each sub site (created from my Site Template) with the new Workflow. I use PowerShell, to cycle each subsite and associate WF to content type list. This is command I used: [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") $site=Get-SPSite "http://sharepoint_root_site" foreach($web in $site.AllWebs){    $list=$web.Lists["MyList"]    $taskList=$web.Lists["Workflow Tasks"]    $historyList=$web.Lists["Workflow History"]    $ct=$list.ContentTypes["MyContenType"]    $culture=New-Object System.Globalization.CultureInfo("en-US")    $wfTemplate=$web.WorkflowTemplates.GetTemplateByName("wfTemplate", $culture)    $associationWF=[Microsoft.SharePoint.Workflow.SPWorkflowAssociation]::CreateListContentTypeAssociation($wfTemplate, "MyWFInSubSi...

Thank you Gavinmckay, you saved me! From his blog:  http://gavinmckay.wordpress.com/2011/08/29/howto-move-or-migrate-sharepoint-2010-list-based-workflows-between-sites-and-site-collections/ I’ve experienced this issue a lot when trying to migrate workflows between test SharePoint 2010 farms and production farms, in particular with workflows attached to lists. When moving a workflow to another site collection or server farm, the association to the list is broken and the workflow cannot be attached to the list. You also cannot use SharePoint designer to fix this via the standard methods as the unattached workflow cannot be reattached to the list. List-based workflows are tied to three different lists – the “main” source list where the data is held (such as a Forms library or custom list), a task list, and a workflow history list. The latter in particular is tricky, because it is a hidden list and cannot be viewed via the normal interface. The fix for this is to modify the sou...

Per la serie "Messaggi di Errore Parlanti", ecco la spiegazione dell'errore indicato qui sotto: Microsoft.SharePoint.SPException: Exception from HRESULT: 0x8102009B  System.Runtime.InteropServices.COMException (0x8102009B): Exception from HRESULT: 0x8102009B at Microsoft.SharePoint.Library.SPRequestInternalClass.AddWorkflowToListItem(String bstrUrl, String bstrListName, Int32 ….. Bene: si sta tentando di avviare una nuova istanza di un workflow, ma quel workflow è già avviato oppure è in errore. Rimuovere le istanze di workflow, interrompere il flusso attivo e .. riprova sarai più fortunato.