I just wanted to say thanks for posting this information.  I was having the exact same issue, and had played with the permissions but with no success.  After checking the workflow out and back in, it magically started working.  Thanks Again.

Cool Stuff

All the steps are clearly mentioned.

Thanks

sdkjfdjf

I think you just saved my mind...

after beating my head on my desk for 2 hours

worked here too, after 3 h of headbanging...

AAAAAAAAAAAARRRRRRRRRGGGGGGGGGGGGHHHHHHHHHHHH!!!!!!!!!!!!!!!!!

For real?  What kind of oddball random "i'd never find it in a million years' problem is this?  *sigh* such is the life of a SharePointer, eh?

Thanks a million.

ALE-FREAKIN'-LUIA!!! 

I have seen this and similar posts in several places.

The problem seems to be that a WF created in SPD works fine for users that were _already given access to the list the WF was attached to_.

When I add new users to the list, they get 'Access Denied' when they try to run the WF. The whole process of requesting access, and adding them to the Workflow permissions list was problematic in that

a) It didn't always work. (in fact I don't remember getting it to work)
b) In a production environment you don't want to have to continually repeat this task.

After trying many, many things I think I finally got it. If you save the WF in SPD (again, even though you make no changes) then the users that were added (Contribute) to the List since the last time you saved the WF now seem to have access to start the WF. Why I do not know, but it seems to be that some part of saving the WF in SPD must 're-associate' it with the list and it's permissions.

Okay so that's good, but each time the key users add people to this list, I need to save the WF in SPD again. Not good. To get around this, the only way I found is to ensure that you have a Group with Contribute access to such a list. Then save the WF to 're-associate' the permissions for that group. Adding users to the group after this save/re-associate sees that these new users DO have access (because the Group was given access before I saved the WF)

Convoluted, yes. Do I know why it works this way - not exactly. But if you are having issues with NEW users being able to start a WF, follow these steps and it may work:

(I'm assuming you have already created the list and the WF attached to it)

1.  Create a new group and give it Contribute access to the List in question.
2. In SPD, go the the WF in Question, open the .xoml file and click through to Finish to 're-save' it.
3. Open the other three WF files (.aspx, .xoml.rules, .xoml.wfconfig.xml) and WITHOUT CHANGING them, click 'Save'
4. Close SPD.


Now, whenever you (or your delegates) need to add users to the List, they should add them to the Group you created. This way they should automatically have access to the WFs, as the the WF was last saved AFTER the group was created.

If for any reason you provide List access to further Groups or individuals, you will need to go through Steps 2-4 above again.

Hope this helps.

Disclaimer: I have done reasonable though not exhaustive testing of this. Some of the things I state are purely from observation and what's really happening in the background may be different altogether. Would be interested if anyone can explain this or if this workaround has helped anybody else out there.

Guys, thanks for the solution!

Hi, i created a form that has to be filled in by an initiator on sharepoint but some colums i want to be greyed so that only me can change them. How do i do that?

This problem has been a thorn in our side for well over a month. We found many articles pointing to simply checking out the workflow in SPD and back in. That never worked for us. Savings all of the xml and aspx pages associated with the workflow did the trick though.

Thanks!

you save us, thanks a 1000000:*