Consider this scenario -

__________________________________________________________

You are trying to setup a document approval workflow in your Sharepoint installation. At the bare minimum, you have two users, one that starts the workflow, and second who approves the workflow. Now, if you are insisting that these could be the same user, yeah, in demonstrations they could be the same user, but never in the real world. And it is these real world scenarios that will come bite you in the ass, not the demos.

So, you have a document library, in which you have one user who starts workflows with "Contribute" permissions setup. A third user, the administrator, has already setup the approval workflow. So let us give these users appropriate names.

- Administrator
- Sahil, who starts the workflow
- Captain America, who approves/rejects the document

At the minimum, you have a task list, and you have the document library.

Now, out of the box, you have various permission levels, "Full Control", "Design", "Contribute", "Read" etc. So, in order for this workflow scenario to work, I would have to give Design rights to both Sahil and Captain America.

Now, what happens in the real world is, Captain America, now has the rights to "Delete" as well as "Approve". What a shame, because the dufus captain America is, he will definitely accidentally delete the assigned tasks, or (shudder) even the document, and complain that your system is broken.

What you need here, is fine grained permission control, to restrict Captain America from deleting, but still allowing him to view pending approval documents, and approve them, and edit rights to the task list, so he can't create new tasks but he can edit existing tasks.

__________________________________________________________

So, now that I've made the case for why you must have fine grained permission control, here is how you'd do it.

There are 2 ways to give fine grained permission control in SharePoint.

At a global level, you can deny certain permissions to everyone in an application. Go to Central Administration > Application Management > User Permissions for Web Application, and uncheck anything you'd rather not have users use. So, if you want users to not be able to delete, uncheck the "Delete Versions" checkbox under List Permissions. This page looks like as shown below:

There are a few important points of mention regarding setting such fine grained permissions at the global level -

1. You can only deny. By default, everything is allowed, unless the site itself prevents the user from receiving a specific permission. This global deny will override the site level allow. In other words, even if you have contributer rights on the site, and you deny "delete" via this method, guess what, you still can't delete.
2. Permissions are split into two halves - site level, and list level. This makes sense because, consider an example - while you can apply a theme to a site, you can't apply a theme to a list. So the permissions are different.
3. This still doesn't help you solve the workflow scenario I described above :-/. For that, you need to come down to the even more granular site level.

At the site level, you can approve/deny permissions using the pre-existing permission groups, "Full Control", "Design", "Contribute", "Read" etc. But, in order to solve the above scenario, you have to create a new permission group level that lets you view/approve but not delete. In order to do so, go to Site Settings > Advanced Permissions >> Settings > Permission Levels. This page looks like this -

Here, when you click on "Add a permission level", you will see the following screen -

.. whoaa!! doesn't this look very very similar to the permissions you set under central administration?

As a matter of fact, the specific permissions you see here, are always a subset of permissions you see under central administration. So if you disallowed a site to have "Manage Lists" permissions allocatable (yuck, if that is a word), then, the fine grained permissions at the site level, won't even show that as an option.

In most non-demonstration scenarios, especially concerning workflows, if you wish to deliver a locked down system (thereby reducing your headache in the long run), you will probably see yourself meddling with this stuff often.