Workspace Process Rights... the definitive answer?

1) Definitely start rigths. Might want to sprink some view or view/particpate, but definitely start rights.

2) If they email is going to the they should be able to action it.

Thought I would add to this thread.  You can normally think of permissions in 2 ways.  First as users that need to start a process and second as users that will need to run reports and/or look at the viewflow diagram.

Start permissions: Users that need to start the process:

Note:  Users assigned as destination users within the workflow:  No permissions are necessary to be set in the K2 Workspace for them to complete their tasks.  As soon as the workflow process assigns them as a destination user they have permissions to perform that task.

Reporting (including looking at the K2 viewflow diagram)

View Participate permissions:  To view K2 reports or to look at the viewflow diagram of process instances when you've been assigned as a destination user you can use View Participate permissions.  However, it’s NOT recommended to give View Participate permissions to all users (domain users group for example) as it might affect reporting performance since K2 needs to do extra queries to see if that person was assigned as a destination user in a particular process instance.   One common misunderstanding with view participate is that if a user started a process instance and even though the user has view participate permissions on a process they still can’t look at reports on that process instance or see the view flow if they haven’t been assigned as a destination user in that process.

View permissions:   Can run reports and see the viewflow diagram of all instances of that process.  Typically given to the business owners.

Hope this helps.

Tim

Permission in K2 are far too broad, IMHO.  For example, for a business owner to be able to redirect or terminate an instance of his process, he has to have admin rights on the process, which also grants him lots of other things you probably don't want them to be able to do.  Instead, they have to call the IT department everytime they need to take one of these actions.  We implemented more than a little code to work around this particular annoyance, but it is workable.

For most of our processes, we grant all domain users Start and View rights.  If a particular process needs authorization rules, we push that to the application layer where the application can make decision like "Did this user originate this process?" or "Was this process submitted on behalf of this user?"  or "Is this person an admin user who can do anything?"  This allows as to customize the authorization rules per process (or even per process instance) and not have to mess around (too much) with K2's identity cache.