SharePoint workflows are document centric in that the base thing the workflow runs on has to be a thing; be it a document or just a list item. The workflow itself is task based, so stuff a user has to do. Now I can put any sort of code in these tasks that I want to and even put complex InfoPath forms in for the user to perform the task. This has been fine on all my previous workflows. But what if I want the tasks to be actual official forms themselves.
The item that the workflow runs on is just some abstract concept like an event. An example could be an accident has happened. There isn't an accident form, but a whole set of forms that need to be completed by different people. Task forms aren't really a nice way to go, because it locks all the forms into the task list. You can only access the forms by not deleting the tasks when complete and going to the workflow summery and following the task links to the InfoPath forms or going straight to the tasks list and doing a filter on particular "accidents".
These are official documents so ideally there would be a library for each type of document and the workflow would orchestrate the completion of the right forms. It would mean each task would have to create a new blank form and then link the user to that form. The user would go complete the form but then have to go back to the task form and click yes I've completed it until the workflow could progress. Well this is short of the workflow monitoring the forms library form for some completion trigger. But then it all gets messy with the user experience from clicking the link in the task email, to open the Infopath task form, to clicking the link in the subsequent Infopath library form and then return through these forms on completion.
It just gets messy trying to retrofit this non document centric sort of workflow into SharePoint. I would really appreciate any input on what might be the best way to do this.
Store the forms as task forms
Store the forms as library forms and create/link from the task forms
Store the forms as library forms and break the workflow down into seperate workflows for each form, all playing their part and triggering the next library.
Using the same form template for both task forms and a forms library and when a task form is complete, copy the xml into the forms library to have a official record outside of the workflow.
Thanks
Related
i'm working in a SharePoint consultant company and one of our customers wants their employees can see all tasks in a single page.
i know there is a web part for get list of all Nintex tasks. but they don't want seeing just link of tasks and click on them and task form get opened. they want a page of all opened task forms.
is a there any way to doing this?
I think you cannot open many tasks forms from a single page. Since you already know about the web part, we don't need talk about it.
You can create a new form which contain all the variable (data) needed for every task you want to update and see, then distribute the data to the other list using Nintex Workflow, you can add web part from the other list at that new form list, so you can update data and see it in one page.
I have a big Infopath form which is part of a complex workflow that involves collecting input and signatures from various users, as well as approvals.
Currently, that same workflow is being done manually — the Infopath form is actually a PDF form and the workflow steps are performed by the actual users who fill out the form, emailing it afterwards to whoever they think it may concern.
I'm on the process of automatizing this using our Sharepoint Server infrastructure, so the first thing was translating the PDF form to an Infopath one. The second would be to produce a Sharepoint workflow that would implement the business process of getting that form properly filled.
So my question is: is it possible to implement a Sharepoint Workflow that sends the full form to the correct users based on the information gathered by the form itself? Ideally, the form would be passed around using the rules defined in the workflow process, users would fill whatever necessary, submit the form and the workflow would continue based on whatever is filled. This form would not only be the initiator form, but the form to be handled in all the workflow tasks.
Breaking the form apart is not desirable as this would confuse our users, and some of them need the overview provided by the full form view. Also, I'd like to use Sharepoint as the form distributor, instead of the email service, if possible.
Any pointers in how to do this would be greatly appreciated.
This is possible.
Here are the pointers in brief:
Create a content type with your infopath form as item form
Create a visual studio workflow that is associated to your content
type
In the code of the workflow you can implement any rules of
processing the form. you're able to get the form data from the list
item you workflow runs in context of.
We are customizing workflow approval form to display the associated list item fields. This will help the approver to verify the list item, he is approving.
The approval form will have to be one of 2 flavors.. this is assuming that you are using Windows Workflow Foundation...
InfoPath workflow form and Windows Workflow Foundation - These are the forms that are normally used for MOSS (not WSS) workflows. In order to provide list data you will need to send the list information up to the task form using the ItemMetadata.xml and SPWorflowTaskProperties.ExtendedProperties[]. If you didn't want to send that info you can try to use VSTA in the form and retrieve said information programmatically into InfoPath.
ASPX Form - Not too many people have created custom task forms (your approval form is really a task form). This form needs to be deployed to the _Layouts directory and is quite difficult to create. I recommend searching Robert Shelton's blog as he has a great example of how to create a SharePoint aspx task form.
Ulysses
I am trying to implement a Workflow, where the user needs to select a destination document library.
I could figure out two possible ways:
Once the user manually starts the workflow, we would display a webpage where he would select the destination document library.
we would initially display a webpage. where User would select the destination.
After clicking a button the workflow would kick start.
Now for possibility "1":
How to redirect from a worlflow to a webpage. [tried Server.Transfer, but failed].
for Possibility "2":
How to start a workflow on button click.
Please also suggest which among the above 2 possibilities is a better solution.
What you need is a workflow initiation form. Exactly how you implement it and how much functionality can get will depend on the type of workflow you are working on, but you should be able to set up something to choose the destination.
I am assuming that you are talking about writing a workflow using Visual Studio. Personally, I would try creating a SharePoint designer workflow first to see if that meets your requirements.
In SharePoint Designer you can create an initiation form that accepts data from a user when they manually start the workflow. If the out of the box actions don't quite do what you need them to, you can create your own reusable custom workflow actions.
I'm currently creating (in Visual Studio) a simple approval workflow within SharePoint so that I can execute some custom code once the user has approved an item. However, it seems that when I don't specify an approval form to use, SharePoint just selects a default one with a "Complete Task" button, but no "Reject" button.
Is there some sort of default approve/reject form I can reference in my code to give users both choices, instead of writing my own page or copy/pasting from the web?
P.S. I'd like to stay away from InfoPath. This is a really simple workflow that shouldn't take much time, and I feel like going the InfoPath route would take much more time than it's worth.
As far as I know, there is no such built-in form. The choices for your own approval form are InfoPath or a custom ASPX. From personal experience using either approach requires considerably more effort to develop than it really should but if InfoPath is available, use it because in my opinion it is quite a lot quicker and I believe has the added advantage that the task can be edited in Outlook (2007).