REF: http://mossipqueen.wordpress.com/2010/01/25/filtering-a-list-by-spd-workflow-status/
I can’t believe I hadn’t attempted to do this earlier but last week I was setting up a sort of dashboard page for a SharePoint audit site and I found I wanted to display a list of the site’s In Progress workflows. I had set up a simple SPD workflow on a list, which acted as the source and storage for the workflow forms, so consequently it had the Workflow Name column to display the status. When I created an “In Progress” view on the list web part, I got a strange Render Error. It became clear that I could not filter the list where the Workflow Name column value = In Progress. So after some digging around I discovered that the SPD workflow statuses are actually represented by numerical values not text, so here are the mappings:
2: In Progress
5: Complete
15: Cancelled
Showing posts with label Workflow. Show all posts
Showing posts with label Workflow. Show all posts
Friday, May 14, 2010
Monday, March 22, 2010
SPD Workflows - Out of the Box
REF: http://www.mannsoftware.com/workflow/Wiki%20Pages/Out%20of%20the%20Box%20Actions%20and%20Conditions.aspx
SPD Workflows all come down to three things:
1. Steps
2. Conditions
3. Actions
That’s it. Master those three things and you’re golden.
Like anything else, the devil’s in the details, so here’s some links to existing information to help you build workflows in SPD:
Office Designer 2007 Overview from MSDN
Ted Pattison Screencast on Channel 9
Create a Workflow from Office Online
Those are all fairly basic, but a good start nonetheless. Here is some additional information:
Steps: A Step in an SPD workflow is a logical grouping of Actions and Conditions. They are used to provide structure
Conditions: Conditions are the circumstances that signal that a given Step in a workflow should execute. The default Conditions available in SPD are:
Condition
Description
Compare
FieldAllows you to specify a value for a column in the list this workflow is attached to. If the payload item has that value in the specified column, then this step will process.
Compare Any Data Source
Allows you to specify a set of values to be compared. Each value can contain either a hard-coded value or a lookup to another list on the site. See the section
Title Field Contains Keyword
Allows you to specify a value to look for in the Title column. If the current list item has that value in the title, then this step will process.
Modified in a Specific Date Span
Allows you to specify begin and end dates for when the list item was modified. If the current list item was modified within this span, then this step will process.
Modified by a Specific Person
Allows you to specify the name of a person. If that person modified the list item, this step will execute.
Created in a Specific Date Span
Same as Modified in a Specific Date Span but works off the list item creation date.
Created by a Specific Person
Same as Modified by a Specific Person but works off the original list item creator, not the last modifier.
The File Type Is a Specific Type
Allows you to specify a certain type of file. If the file payload matches this file extension, the step will process
The File Size in a Specific Range
Allows you to specify a range of kilobytes. If the file of Kilobytes payload falls within this range, the step will process.
Actions: An Action is what happens in a workflow step – they are the tasks that will be completed by the workflow as part of that step. The default Actions available in SPD are:
Action
Description
Add Time to Date
Allows you to work with date values and store the result in a variable. You can add (or subtract, by indicating a negative value) time (minutes, hours, days, months, or years) to a specified date and store the result in either an existing variable or in a new variable created in this step.
Assign a Form to a Group
Launches a custom wizard that allows you to easily build a form to collect information from users. The wizard is similar to the Variables Editor discussed in a moment. You can indicate which users are assigned the survey as part of the configuration for this action.
Assign a To-do Item
Launches a dialog box that allows you to specify the parameters for creating a simple task for a specified user.
Build Dynamic String
Configure this step to create a string value and assign it to a variable. The string value can contain values retrieved from the current workflow instance by using lookups. We discuss lookups later in this chapter. The variable used to store the string value can be either preexisting or created as part of this action.
Check In Item
Checks in an item so other users can edit it. You can specify Current Item or provide a column name and value to identify which item to check in. Also allows you to specify a check-in comment, which can be either hard-coded or set via a workflow lookup.
Check Out Item
Checks out an item so other users cannot edit it. You can specify Current Item or provide a column name and value to identify which item to check out.
Collect Data from a User
Creates and assigns a task to the specified user. Tasks are used to collect specific information from the assigned user or to have the user complete a process. The ID of the task is stored in a variable so that the information from that task is available later in the workflow via a workflow lookup. Configuring this action will launch the custom task wizard, which is similar to the Variables Editor discussed in a moment. This action is similar to the Assign a To-Do Item action, but allows you to collect information for later use instead of just creating a task.
Copy List Item
Creates an exact duplicate of an existing list item in a different list on the current site. You specify both the source and destination lists. You can specify Current Item or provide a column name and value to identify which item to copy.
Create List Item
Creates a new list item in any list on the current site. You specify the list as well as values for all necessary columns. Values can either be hard-coded or based on a workflow lookup.
Delete Item
Deletes an item from a list on the current site. You can specify Current Item or provide a column name and value to identify which item to delete.
Discard Check Out Item
Pretty self-explanatory, but this allows you to undo the checkout of an item. All changes to that item will be lost.
Do Calculation
Performs a simple calculation (plus, minus, multiply, divide, modulo) with two values, which you can either specify or base on a workflow lookup. The results of the calculation are stored in a variable. Typically, this variable would be one created specifically for this workflow.
Log to History List
Allows you to write an entry to the designated history list for this workflow instance. You can use either fixed text or a workflow lookup value (but not both) as the text to be written.
Pause for Duration
Allows you to specify that the workflow should suspend processing for a time period you specify (in days, hours, and minutes) when you configure this action.
Pause Until Date
Similar to the previous action, except that you configure a specific date on which to continue processing the workflow.
Send an Email
Sends an email when it is executed. The action can be customized to specify the recipient, CC, subject, and body of the message. Each of these fields can be either hard-coded or based on formulas, lookups, or workflow variables.
Set Content Approval Status
Allows you to specify the current status of the payload item. You can also specify comments, but keep in mind that those comments will be the same for every instance of this workflow unless you use lookups.
Set Field in Current Item
Allows you to set the value of a specific column in the payload item to a specified value. You can specify this value with either fixed text or a workflow lookup value (but not both).
Set Time Portion of Date/Time Field
Similar to the Add Time to Date action, except that you specify a specific value for hours and minutes (i.e., not a relative time—plus 5 minutes from when the action executes) and store the results in a variable.
Set Workflow Variable
Sets a variable for this workflow to a specified value. The value can be either hard-coded or set via a workflow lookup. You can reference a previously created variable or create a new one.
Stop Workflow
Causes the workflow to stop processing. You can specify text to be logged to the history list with either fixed text or a lookup.
Update List Item
Updates one or more existing columns in one or more lists. You can specify the list(s), the column(s), and the value(s). You can also specify Current Item to indicate the item that triggered the current workflow instance.
Wait for Field Change in Current Item
Pauses the workflow until the specified column for this item from the attached SharePoint list equals the value specified. The value can be hard-coded or based on a workflow lookup.
It is important to note that you can create custom Conditions and custom Actions and use them in your SPD workflow. We’ll cover that in a later posting.
There are a few things that you need to understand about a workflow developed with SPD:
1. They operate on a single List. When you start building the workflow, you pick the list to attach it to. Once that is set, there’s no changing it. You can’t take the workflow and attach it to another list or the same list type on another site
2. You can’t deploy SPD-developed workflows from one environment to another – or rather, you can’t deploy without recreating the workflow on the new environment
3. You can’t debug SPD workflows
4. You must have the .Net Framework 3.0 on the machine where you are running SPD
SPD Workflows all come down to three things:
1. Steps
2. Conditions
3. Actions
That’s it. Master those three things and you’re golden.
Like anything else, the devil’s in the details, so here’s some links to existing information to help you build workflows in SPD:
Office Designer 2007 Overview from MSDN
Ted Pattison Screencast on Channel 9
Create a Workflow from Office Online
Those are all fairly basic, but a good start nonetheless. Here is some additional information:
Steps: A Step in an SPD workflow is a logical grouping of Actions and Conditions. They are used to provide structure
Conditions: Conditions are the circumstances that signal that a given Step in a workflow should execute. The default Conditions available in SPD are:
Condition
Description
Compare
FieldAllows you to specify a value for a column in the list this workflow is attached to. If the payload item has that value in the specified column, then this step will process.
Compare Any Data Source
Allows you to specify a set of values to be compared. Each value can contain either a hard-coded value or a lookup to another list on the site. See the section
Title Field Contains Keyword
Allows you to specify a value to look for in the Title column. If the current list item has that value in the title, then this step will process.
Modified in a Specific Date Span
Allows you to specify begin and end dates for when the list item was modified. If the current list item was modified within this span, then this step will process.
Modified by a Specific Person
Allows you to specify the name of a person. If that person modified the list item, this step will execute.
Created in a Specific Date Span
Same as Modified in a Specific Date Span but works off the list item creation date.
Created by a Specific Person
Same as Modified by a Specific Person but works off the original list item creator, not the last modifier.
The File Type Is a Specific Type
Allows you to specify a certain type of file. If the file payload matches this file extension, the step will process
The File Size in a Specific Range
Allows you to specify a range of kilobytes. If the file of Kilobytes payload falls within this range, the step will process.
Actions: An Action is what happens in a workflow step – they are the tasks that will be completed by the workflow as part of that step. The default Actions available in SPD are:
Action
Description
Add Time to Date
Allows you to work with date values and store the result in a variable. You can add (or subtract, by indicating a negative value) time (minutes, hours, days, months, or years) to a specified date and store the result in either an existing variable or in a new variable created in this step.
Assign a Form to a Group
Launches a custom wizard that allows you to easily build a form to collect information from users. The wizard is similar to the Variables Editor discussed in a moment. You can indicate which users are assigned the survey as part of the configuration for this action.
Assign a To-do Item
Launches a dialog box that allows you to specify the parameters for creating a simple task for a specified user.
Build Dynamic String
Configure this step to create a string value and assign it to a variable. The string value can contain values retrieved from the current workflow instance by using lookups. We discuss lookups later in this chapter. The variable used to store the string value can be either preexisting or created as part of this action.
Check In Item
Checks in an item so other users can edit it. You can specify Current Item or provide a column name and value to identify which item to check in. Also allows you to specify a check-in comment, which can be either hard-coded or set via a workflow lookup.
Check Out Item
Checks out an item so other users cannot edit it. You can specify Current Item or provide a column name and value to identify which item to check out.
Collect Data from a User
Creates and assigns a task to the specified user. Tasks are used to collect specific information from the assigned user or to have the user complete a process. The ID of the task is stored in a variable so that the information from that task is available later in the workflow via a workflow lookup. Configuring this action will launch the custom task wizard, which is similar to the Variables Editor discussed in a moment. This action is similar to the Assign a To-Do Item action, but allows you to collect information for later use instead of just creating a task.
Copy List Item
Creates an exact duplicate of an existing list item in a different list on the current site. You specify both the source and destination lists. You can specify Current Item or provide a column name and value to identify which item to copy.
Create List Item
Creates a new list item in any list on the current site. You specify the list as well as values for all necessary columns. Values can either be hard-coded or based on a workflow lookup.
Delete Item
Deletes an item from a list on the current site. You can specify Current Item or provide a column name and value to identify which item to delete.
Discard Check Out Item
Pretty self-explanatory, but this allows you to undo the checkout of an item. All changes to that item will be lost.
Do Calculation
Performs a simple calculation (plus, minus, multiply, divide, modulo) with two values, which you can either specify or base on a workflow lookup. The results of the calculation are stored in a variable. Typically, this variable would be one created specifically for this workflow.
Log to History List
Allows you to write an entry to the designated history list for this workflow instance. You can use either fixed text or a workflow lookup value (but not both) as the text to be written.
Pause for Duration
Allows you to specify that the workflow should suspend processing for a time period you specify (in days, hours, and minutes) when you configure this action.
Pause Until Date
Similar to the previous action, except that you configure a specific date on which to continue processing the workflow.
Send an Email
Sends an email when it is executed. The action can be customized to specify the recipient, CC, subject, and body of the message. Each of these fields can be either hard-coded or based on formulas, lookups, or workflow variables.
Set Content Approval Status
Allows you to specify the current status of the payload item. You can also specify comments, but keep in mind that those comments will be the same for every instance of this workflow unless you use lookups.
Set Field in Current Item
Allows you to set the value of a specific column in the payload item to a specified value. You can specify this value with either fixed text or a workflow lookup value (but not both).
Set Time Portion of Date/Time Field
Similar to the Add Time to Date action, except that you specify a specific value for hours and minutes (i.e., not a relative time—plus 5 minutes from when the action executes) and store the results in a variable.
Set Workflow Variable
Sets a variable for this workflow to a specified value. The value can be either hard-coded or set via a workflow lookup. You can reference a previously created variable or create a new one.
Stop Workflow
Causes the workflow to stop processing. You can specify text to be logged to the history list with either fixed text or a lookup.
Update List Item
Updates one or more existing columns in one or more lists. You can specify the list(s), the column(s), and the value(s). You can also specify Current Item to indicate the item that triggered the current workflow instance.
Wait for Field Change in Current Item
Pauses the workflow until the specified column for this item from the attached SharePoint list equals the value specified. The value can be hard-coded or based on a workflow lookup.
It is important to note that you can create custom Conditions and custom Actions and use them in your SPD workflow. We’ll cover that in a later posting.
There are a few things that you need to understand about a workflow developed with SPD:
1. They operate on a single List. When you start building the workflow, you pick the list to attach it to. Once that is set, there’s no changing it. You can’t take the workflow and attach it to another list or the same list type on another site
2. You can’t deploy SPD-developed workflows from one environment to another – or rather, you can’t deploy without recreating the workflow on the new environment
3. You can’t debug SPD workflows
4. You must have the .Net Framework 3.0 on the machine where you are running SPD
Thursday, February 4, 2010
Missing Completed Workflows History
REF: http://social.msdn.microsoft.com/Forums/en/sharepointworkflow/thread/b15b27e2-3033-418b-9731-968273d7423e
P: I cannot find any workflow histories on approved documents that were approved 2 months or more ago.
A: The workflow data is purged from the MOSS Workflow database table after 60 days. Based on calls to Microsoft about this, it was by design and for performance reasons. However, what good it the workflow functionality if proof of the workflows are deleted? How can companies meet various industry auditing requirements for SOX, ISO, TS, etc? Microsoft gave us only one option: changing the 60 days to something higher by writing a script modifying the SPWorkflowTemplate.AutoCleanupDays property of the workflow associations. But this does not bring the deleted data back?
For anyone seriously considering using the MOSS workflows, I would advise you disable the "Workflow Auto Cleanup" timer service in Central Admin (central --> Operations -->Timer Job Definitions) to prevent any further deletions of your workflow data. A lot of agonizing work went into researching this problem because it was not documented by Microsoft. Not even the MOSS database schema. I had to reverse engineer the database and study the stored procedures to uncover the truth about what happened to my data.
READ More at above link
P: I cannot find any workflow histories on approved documents that were approved 2 months or more ago.
A: The workflow data is purged from the MOSS Workflow database table after 60 days. Based on calls to Microsoft about this, it was by design and for performance reasons. However, what good it the workflow functionality if proof of the workflows are deleted? How can companies meet various industry auditing requirements for SOX, ISO, TS, etc? Microsoft gave us only one option: changing the 60 days to something higher by writing a script modifying the SPWorkflowTemplate.AutoCleanupDays property of the workflow associations. But this does not bring the deleted data back?
For anyone seriously considering using the MOSS workflows, I would advise you disable the "Workflow Auto Cleanup" timer service in Central Admin (central --> Operations -->Timer Job Definitions) to prevent any further deletions of your workflow data. A lot of agonizing work went into researching this problem because it was not documented by Microsoft. Not even the MOSS database schema. I had to reverse engineer the database and study the stored procedures to uncover the truth about what happened to my data.
READ More at above link
Friday, January 22, 2010
How to get an SPD Workflow to Run at a Specific Time
REF: http://www.endusersharepoint.com/2010/01/11/how-to-get-an-spd-workflow-to-run-at-a-specific-time-employee-vacation-reminder-part-1/
In this article, we’re going to look at how to fire off an SPD workflow at a specific time of day for a fixed number of days. Thanks to “IAIN” on the “STP Forums” (once again) for asking the question on how to build this out for use with an employee vacation tracking list.
The Setup
The question we have is, how do we tell a workflow to fire off at a specific time of day (8 AM for example) in order to send out an email reminder to let people know who’s on vacation for that day? Additionally (and adding in another level of complexity), how can we make it somewhat-automated so that when the employee returns from vacation, the workflow process ends?
Both pieces of this would be rather simple in the programming world, but for an SPD Workflow, we’ll have to get a bit creative in order to create this functionality (all “out-of-the-box” as well).
In this article, we’re going to look at how to fire off an SPD workflow at a specific time of day for a fixed number of days. Thanks to “IAIN” on the “STP Forums” (once again) for asking the question on how to build this out for use with an employee vacation tracking list.
The Setup
The question we have is, how do we tell a workflow to fire off at a specific time of day (8 AM for example) in order to send out an email reminder to let people know who’s on vacation for that day? Additionally (and adding in another level of complexity), how can we make it somewhat-automated so that when the employee returns from vacation, the workflow process ends?
Both pieces of this would be rather simple in the programming world, but for an SPD Workflow, we’ll have to get a bit creative in order to create this functionality (all “out-of-the-box” as well).
Thursday, January 14, 2010
Default Conditions and Actions available in SPD list
Conditions
Compare
FieldAllows you to specify a value for a column in the list this workflow is attached to. If the payload item has that value in the specified column, then this step will process.
Compare Any Data Source
Allows you to specify a set of values to be compared. Each value can contain either a hard-coded value or a lookup to another list on the site. See the section
Title Field Contains Keyword
Allows you to specify a value to look for in the Title column. If the current list item has that value in the title, then this step will process.
Modified in a Specific Date Span
Allows you to specify begin and end dates for when the list item was modified. If the current list item was modified within this span, then this step will process.
Modified by a Specific Person
Allows you to specify the name of a person. If that person modified the list item, this step will execute.
Created in a Specific Date Span
Same as Modified in a Specific Date Span but works off the list item creation date.
Created by a Specific Person
Same as Modified by a Specific Person but works off the original list item creator, not the last modifier.
The File Type Is a Specific Type
Allows you to specify a certain type of file. If the file payload matches this file extension, the step will process
The File Size in a Specific Range
Allows you to specify a range of kilobytes. If the file of Kilobytes payload falls within this range, the step will process.
-----------------------------------------------------------------------------------------
Actions
Add Time to Date
Allows you to work with date values and store the result in a variable. You can add (or subtract, by indicating a negative value) time (minutes, hours, days, months, or years) to a specified date and store the result in either an existing variable or in a new variable created in this step.
Assign a Form to a Group
Launches a custom wizard that allows you to easily build a form to collect information from users. The wizard is similar to the Variables Editor discussed in a moment. You can indicate which users are assigned the survey as part of the configuration for this action.
Assign a To-do Item
Launches a dialog box that allows you to specify the parameters for creating a simple task for a specified user.
Build Dynamic String
Configure this step to create a string value and assign it to a variable. The string value can contain values retrieved from the current workflow instance by using lookups. We discuss lookups later in this chapter. The variable used to store the string value can be either preexisting or created as part of this action.
Check In Item
Checks in an item so other users can edit it. You can specify Current Item or provide a column name and value to identify which item to check in. Also allows you to specify a check-in comment, which can be either hard-coded or set via a workflow lookup.
Check Out Item
Checks out an item so other users cannot edit it. You can specify Current Item or provide a column name and value to identify which item to check out.
Collect Data from a User
Creates and assigns a task to the specified user. Tasks are used to collect specific information from the assigned user or to have the user complete a process. The ID of the task is stored in a variable so that the information from that task is available later in the workflow via a workflow lookup. Configuring this action will launch the custom task wizard, which is similar to the Variables Editor discussed in a moment. This action is similar to the Assign a To-Do Item action, but allows you to collect information for later use instead of just creating a task.
Copy List Item
Creates an exact duplicate of an existing list item in a different list on the current site. You specify both the source and destination lists. You can specify Current Item or provide a column name and value to identify which item to copy.
Create List Item
Creates a new list item in any list on the current site. You specify the list as well as values for all necessary columns. Values can either be hard-coded or based on a workflow lookup.
Delete Item
Deletes an item from a list on the current site. You can specify Current Item or provide a column name and value to identify which item to delete.
Discard Check Out Item
Pretty self-explanatory, but this allows you to undo the checkout of an item. All changes to that item will be lost.
Do Calculation
Performs a simple calculation (plus, minus, multiply, divide, modulo) with two values, which you can either specify or base on a workflow lookup. The results of the calculation are stored in a variable. Typically, this variable would be one created specifically for this workflow.
Log to History List
Allows you to write an entry to the designated history list for this workflow instance. You can use either fixed text or a workflow lookup value (but not both) as the text to be written.
Pause for Duration
Allows you to specify that the workflow should suspend processing for a time period you specify (in days, hours, and minutes) when you configure this action.
Pause Until Date
Similar to the previous action, except that you configure a specific date on which to continue processing the workflow.
Send an Email
Sends an email when it is executed. The action can be customized to specify the recipient, CC, subject, and body of the message. Each of these fields can be either hard-coded or based on formulas, lookups, or workflow variables.
Set Content Approval Status
Allows you to specify the current status of the payload item. You can also specify comments, but keep in mind that those comments will be the same for every instance of this workflow unless you use lookups.
Set Field in Current Item
Allows you to set the value of a specific column in the payload item to a specified value. You can specify this value with either fixed text or a workflow lookup value (but not both).
Set Time Portion of Date/Time Field
Similar to the Add Time to Date action, except that you specify a specific value for hours and minutes (i.e., not a relative time—plus 5 minutes from when the action executes) and store the results in a variable.
Set Workflow Variable
Sets a variable for this workflow to a specified value. The value can be either hard-coded or set via a workflow lookup. You can reference a previously created variable or create a new one.
Stop Workflow
Causes the workflow to stop processing. You can specify text to be logged to the history list with either fixed text or a lookup.
Update List Item
Updates one or more existing columns in one or more lists. You can specify the list(s), the column(s), and the value(s). You can also specify Current Item to indicate the item that triggered the current workflow instance.
Wait for Field Change in Current Item
Pauses the workflow until the specified column for this item from the attached SharePoint list equals the value specified. The value can be hard-coded or based on a workflow lookup.
Compare
FieldAllows you to specify a value for a column in the list this workflow is attached to. If the payload item has that value in the specified column, then this step will process.
Compare Any Data Source
Allows you to specify a set of values to be compared. Each value can contain either a hard-coded value or a lookup to another list on the site. See the section
Title Field Contains Keyword
Allows you to specify a value to look for in the Title column. If the current list item has that value in the title, then this step will process.
Modified in a Specific Date Span
Allows you to specify begin and end dates for when the list item was modified. If the current list item was modified within this span, then this step will process.
Modified by a Specific Person
Allows you to specify the name of a person. If that person modified the list item, this step will execute.
Created in a Specific Date Span
Same as Modified in a Specific Date Span but works off the list item creation date.
Created by a Specific Person
Same as Modified by a Specific Person but works off the original list item creator, not the last modifier.
The File Type Is a Specific Type
Allows you to specify a certain type of file. If the file payload matches this file extension, the step will process
The File Size in a Specific Range
Allows you to specify a range of kilobytes. If the file of Kilobytes payload falls within this range, the step will process.
-----------------------------------------------------------------------------------------
Actions
Add Time to Date
Allows you to work with date values and store the result in a variable. You can add (or subtract, by indicating a negative value) time (minutes, hours, days, months, or years) to a specified date and store the result in either an existing variable or in a new variable created in this step.
Assign a Form to a Group
Launches a custom wizard that allows you to easily build a form to collect information from users. The wizard is similar to the Variables Editor discussed in a moment. You can indicate which users are assigned the survey as part of the configuration for this action.
Assign a To-do Item
Launches a dialog box that allows you to specify the parameters for creating a simple task for a specified user.
Build Dynamic String
Configure this step to create a string value and assign it to a variable. The string value can contain values retrieved from the current workflow instance by using lookups. We discuss lookups later in this chapter. The variable used to store the string value can be either preexisting or created as part of this action.
Check In Item
Checks in an item so other users can edit it. You can specify Current Item or provide a column name and value to identify which item to check in. Also allows you to specify a check-in comment, which can be either hard-coded or set via a workflow lookup.
Check Out Item
Checks out an item so other users cannot edit it. You can specify Current Item or provide a column name and value to identify which item to check out.
Collect Data from a User
Creates and assigns a task to the specified user. Tasks are used to collect specific information from the assigned user or to have the user complete a process. The ID of the task is stored in a variable so that the information from that task is available later in the workflow via a workflow lookup. Configuring this action will launch the custom task wizard, which is similar to the Variables Editor discussed in a moment. This action is similar to the Assign a To-Do Item action, but allows you to collect information for later use instead of just creating a task.
Copy List Item
Creates an exact duplicate of an existing list item in a different list on the current site. You specify both the source and destination lists. You can specify Current Item or provide a column name and value to identify which item to copy.
Create List Item
Creates a new list item in any list on the current site. You specify the list as well as values for all necessary columns. Values can either be hard-coded or based on a workflow lookup.
Delete Item
Deletes an item from a list on the current site. You can specify Current Item or provide a column name and value to identify which item to delete.
Discard Check Out Item
Pretty self-explanatory, but this allows you to undo the checkout of an item. All changes to that item will be lost.
Do Calculation
Performs a simple calculation (plus, minus, multiply, divide, modulo) with two values, which you can either specify or base on a workflow lookup. The results of the calculation are stored in a variable. Typically, this variable would be one created specifically for this workflow.
Log to History List
Allows you to write an entry to the designated history list for this workflow instance. You can use either fixed text or a workflow lookup value (but not both) as the text to be written.
Pause for Duration
Allows you to specify that the workflow should suspend processing for a time period you specify (in days, hours, and minutes) when you configure this action.
Pause Until Date
Similar to the previous action, except that you configure a specific date on which to continue processing the workflow.
Send an Email
Sends an email when it is executed. The action can be customized to specify the recipient, CC, subject, and body of the message. Each of these fields can be either hard-coded or based on formulas, lookups, or workflow variables.
Set Content Approval Status
Allows you to specify the current status of the payload item. You can also specify comments, but keep in mind that those comments will be the same for every instance of this workflow unless you use lookups.
Set Field in Current Item
Allows you to set the value of a specific column in the payload item to a specified value. You can specify this value with either fixed text or a workflow lookup value (but not both).
Set Time Portion of Date/Time Field
Similar to the Add Time to Date action, except that you specify a specific value for hours and minutes (i.e., not a relative time—plus 5 minutes from when the action executes) and store the results in a variable.
Set Workflow Variable
Sets a variable for this workflow to a specified value. The value can be either hard-coded or set via a workflow lookup. You can reference a previously created variable or create a new one.
Stop Workflow
Causes the workflow to stop processing. You can specify text to be logged to the history list with either fixed text or a lookup.
Update List Item
Updates one or more existing columns in one or more lists. You can specify the list(s), the column(s), and the value(s). You can also specify Current Item to indicate the item that triggered the current workflow instance.
Wait for Field Change in Current Item
Pauses the workflow until the specified column for this item from the attached SharePoint list equals the value specified. The value can be hard-coded or based on a workflow lookup.
Creating Permanent SharePoint Designer Workflow Audit Trails
Overview: Workflow Audit Trails
Just about any important workflow solution requires an audit trail. We want to know who approved a particular document and when. We want to know when a task was assigned to someone and when they completed it. We leave debugging style messages in our workflow so that we can go back, after the fact, and understand who did what and when they did it so that we can improve the process. There are many good reasons to leave behind audit information.
SharePoint Designer makes this easy with the “log to history” action. This little action allows us to save just about any message we want to the workflow history.
There is a terrible flaw in this, however. Out of the box, workflow history is not permanent.
SharePoint runs a process every day that looks for and purges data from all workflow history lists. This process removes any item which is more than 60 days old! This can be a terrible shock, particularly when you’ve built a business solution that requires a long term audit trail, such as approvals on financial transactions or security requests for systems access. Even if you don’t have a strong requirement, legal or otherwise for an audit trail, it’s still nice to have that audit trail.
Why does SharePoint do this? There’s a good technical reason and it relates to the famous “2000 item limit.” Microsoft recommends that a given list or document library should normally only show 2000 items at a time. After that, SharePoint’s overall performance can degrade and hurt the end user experience. At the same time, SharePoint workflow history is actually a list, just like any other list. It’s a hidden list, so you can’t see from “view all content,” but it’s a list. As a result, it needs to conform to the same 2,000 item guideline. Microsoft solves this by purging the data from the list by arbitrarily deleting older entries.
So, Microsoft solves the technical problem for us, but we’re level with a business problem. How do we solve this? There are at least five approaches.
Solution One: Live With It
The most obvious solution is to simply live with it. This is a no-cost option and if you don’t need a permanent audit trail, you’re better off allowing SharePoint to purge it anyway. Sixty days is a pretty good default window.
Solution Two: Re-configure the SharePoint Job
Like so many options in SharePoint, the 60 day window is itself configurable. If 60 days is too short, increase it to 90 days or 365 days or whatever is required. We do this using stsadm. This technet article describes this in a little more detail: http://technet.microsoft.com/en-us/library/cc424956.aspx
There is a problem with this approach. If you disable this process altogether, or set the window to something very long (10 years, for example), your workflow history list will grow and grow and … grow. And this causes problems by itself. If it grows into 1000’s and 10’s of thousands of entries (or even larger), performance will probably degrade. It could even become uselessly slow. I don’t have personal experience with it, but keep this problem in mind.
Solution Three: Use a Custom List
Last week, I wrote about using a custom list to create flexible workflow solutions. Instead of hard coding data in a list (such an approver’s email address), instead pull those values out of the workflow and save them in a custom list. At run-time, the workflow looks up the value in that custom list. That way, if someone changes jobs, all you need to do is update the custom list. You don’t need to use SharePoint designer for that purpose.
If we can a custom list to extract data, we can also use a custom list to save an audit history. Instead of using “log to history” we can use “create list item” actions to create our own audit trail with our own audit information. This gives us full control over when and how this audit information is purged (if ever).
We still have a 2,000 item guideline problem. But now we have the power. With that power comes responsibility and all that, but at least it’s in our hands.
I plan to write up a fully functioning example of this in the next week or two.
Solution Four: Embed audit history in the data
This is a bit of a special case. I had the opporuntity to work with a client that used an InfoPath form in conjunction with a workflow process to manage on-boarding new hires. The InfoPath form used an “administrator view” to capture and provide a single view of audit data. As the workflow progressed through its steps, it would record the who/when bits and save them directly onto the form.
The advantage here is that the form becomes both a place to enter some data, but also its own audit trail. The audit trail survives as long as the form itself survives.
A similar approach could be taken with a custom list or document library, although you need to get a little clever if there are complex auditing requirements.
The downside to this is that the data could be “adjusted” by someone with the right privileges and that can defeat the purpose of an audit trail in the first place. Normally, we want our audit trails to be write-once and read-forever. This is more difficult to accomplish when the form itself stores the audit data.
Solution Five: Use Built-in SharePoint Auditing
Lastly, use SharePoint’s built it auditing capability.
SharePoint provides a rich auditing capability. See here for all the gory details: http://technet.microsoft.com/en-us/library/cc424956.aspx
There’s a lot of material in there, but the key takeaways are:
Conclusion
One way of looking at SharePoint Designer workflow and auditing is that, frankly, it sets us up to fail. Many people don’t realize that potentially precious audit messages are purged after 60 days. SharePoint Designer doesn’t warn us that this is going to happen. SharePoint itself doesn’t give us any clue. There ought to be warning messages all over the place because it’s perfectly natural to assume that workflow history is going to be permanent.
In this case, SharePoint gives us auditing with one hand, takes it away with another, but thankfully, gives it back to us with one or more of the solutions described in this article.
If you’ve been blithely assuming that your workflow audits are safe, they are not. If you need those audit trails, plan on designing a solution sooner rather than later, because the clock is ticking.
Postscript
You can see my MindJet Mindmap for this article here: Auditing Workflows.pdf
REF: http://www.endusersharepoint.com/2009/01/27/creating-permanent-sharepoint-designer-workflow-audit-trails/
Just about any important workflow solution requires an audit trail. We want to know who approved a particular document and when. We want to know when a task was assigned to someone and when they completed it. We leave debugging style messages in our workflow so that we can go back, after the fact, and understand who did what and when they did it so that we can improve the process. There are many good reasons to leave behind audit information.
SharePoint Designer makes this easy with the “log to history” action. This little action allows us to save just about any message we want to the workflow history.
There is a terrible flaw in this, however. Out of the box, workflow history is not permanent.
SharePoint runs a process every day that looks for and purges data from all workflow history lists. This process removes any item which is more than 60 days old! This can be a terrible shock, particularly when you’ve built a business solution that requires a long term audit trail, such as approvals on financial transactions or security requests for systems access. Even if you don’t have a strong requirement, legal or otherwise for an audit trail, it’s still nice to have that audit trail.
Why does SharePoint do this? There’s a good technical reason and it relates to the famous “2000 item limit.” Microsoft recommends that a given list or document library should normally only show 2000 items at a time. After that, SharePoint’s overall performance can degrade and hurt the end user experience. At the same time, SharePoint workflow history is actually a list, just like any other list. It’s a hidden list, so you can’t see from “view all content,” but it’s a list. As a result, it needs to conform to the same 2,000 item guideline. Microsoft solves this by purging the data from the list by arbitrarily deleting older entries.
So, Microsoft solves the technical problem for us, but we’re level with a business problem. How do we solve this? There are at least five approaches.
Solution One: Live With It
The most obvious solution is to simply live with it. This is a no-cost option and if you don’t need a permanent audit trail, you’re better off allowing SharePoint to purge it anyway. Sixty days is a pretty good default window.
Solution Two: Re-configure the SharePoint Job
Like so many options in SharePoint, the 60 day window is itself configurable. If 60 days is too short, increase it to 90 days or 365 days or whatever is required. We do this using stsadm. This technet article describes this in a little more detail: http://technet.microsoft.com/en-us/library/cc424956.aspx
There is a problem with this approach. If you disable this process altogether, or set the window to something very long (10 years, for example), your workflow history list will grow and grow and … grow. And this causes problems by itself. If it grows into 1000’s and 10’s of thousands of entries (or even larger), performance will probably degrade. It could even become uselessly slow. I don’t have personal experience with it, but keep this problem in mind.
Solution Three: Use a Custom List
Last week, I wrote about using a custom list to create flexible workflow solutions. Instead of hard coding data in a list (such an approver’s email address), instead pull those values out of the workflow and save them in a custom list. At run-time, the workflow looks up the value in that custom list. That way, if someone changes jobs, all you need to do is update the custom list. You don’t need to use SharePoint designer for that purpose.
If we can a custom list to extract data, we can also use a custom list to save an audit history. Instead of using “log to history” we can use “create list item” actions to create our own audit trail with our own audit information. This gives us full control over when and how this audit information is purged (if ever).
We still have a 2,000 item guideline problem. But now we have the power. With that power comes responsibility and all that, but at least it’s in our hands.
I plan to write up a fully functioning example of this in the next week or two.
Solution Four: Embed audit history in the data
This is a bit of a special case. I had the opporuntity to work with a client that used an InfoPath form in conjunction with a workflow process to manage on-boarding new hires. The InfoPath form used an “administrator view” to capture and provide a single view of audit data. As the workflow progressed through its steps, it would record the who/when bits and save them directly onto the form.
The advantage here is that the form becomes both a place to enter some data, but also its own audit trail. The audit trail survives as long as the form itself survives.
A similar approach could be taken with a custom list or document library, although you need to get a little clever if there are complex auditing requirements.
The downside to this is that the data could be “adjusted” by someone with the right privileges and that can defeat the purpose of an audit trail in the first place. Normally, we want our audit trails to be write-once and read-forever. This is more difficult to accomplish when the form itself stores the audit data.
Solution Five: Use Built-in SharePoint Auditing
Lastly, use SharePoint’s built it auditing capability.
SharePoint provides a rich auditing capability. See here for all the gory details: http://technet.microsoft.com/en-us/library/cc424956.aspx
There’s a lot of material in there, but the key takeaways are:
- MOSS provides a better all-around solution over WSS.
- It’s not a particularly end user friendly solution, especially on the WSS side.
- It’s permanent.
- It’s transportable. If you upgrade hardware or carry out a wide variety of backend administrative tasks, your audit history will travel with you.
- It’s extensible by way of programming. It’s not extensible in an end user friendly way, but if you partner up with your developer colleagues, you have a lot of good options.
Conclusion
One way of looking at SharePoint Designer workflow and auditing is that, frankly, it sets us up to fail. Many people don’t realize that potentially precious audit messages are purged after 60 days. SharePoint Designer doesn’t warn us that this is going to happen. SharePoint itself doesn’t give us any clue. There ought to be warning messages all over the place because it’s perfectly natural to assume that workflow history is going to be permanent.
In this case, SharePoint gives us auditing with one hand, takes it away with another, but thankfully, gives it back to us with one or more of the solutions described in this article.
If you’ve been blithely assuming that your workflow audits are safe, they are not. If you need those audit trails, plan on designing a solution sooner rather than later, because the clock is ticking.
Postscript
You can see my MindJet Mindmap for this article here: Auditing Workflows.pdf
REF: http://www.endusersharepoint.com/2009/01/27/creating-permanent-sharepoint-designer-workflow-audit-trails/
Subscribe to:
Posts (Atom)