"Execute as Owner" workflow is executed as triggering user

(0) Share

Report

Posted on by Community Member

I have a synchronous workflow, which deletes values from secured fields. A user should be able to trigger the workflow, although he doesn't have the privilege to change these fields. For that purpose, i used the workflow option "execute as" and set it to "owner of workflow". But, when the user triggered the workflow, he gets the error message, that he doesn't have the privilege...

The event log entry shows, that the user context of the workflow was the triggering user and not (like expected) the owner of the workflow.

Am I missing anything or is this a huge bug???

Any help appreciated!

*This post is locked for comments

I have the same question (0)

All responses (22)

Answers (1)

Guido Preite 54,086 Moderator on at

Like (0)

Report

exact CRM 2013 version? OnPremise,Online, rollup installed,...

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Of course :) CRM 2013 SP 1 - OnPremise

Was this reply helpful? Yes No
Suggested answer

Bojan.borisovski@ho... 480 on at

Like (0)

Report

Hi Christian,

Can you post the detailed error message log.

Usually it shows on which entity the privilege is missing.

But it seems, that if your user doesn't have the privilege to edit change the fields, and workflow executes in context of that user, it very logical that the workflow will fail with missing privileges, as the user it self is missing them.

If you want the workflow to edit the fields, it should be set to execute as the owner of the workflow, and the owner of the workflow to have privileges on editing these fields. But if i understand correctly this is nto working.

You can also try to restart async crm service, and re-publishing the changes and see if it helps

Hope it helps.

Bojan.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Bojan,

That's what i did :)

I set the workflow to execute as the owner (my user account - admin role) and a different user (standard sales role) try to execute this workflow.

When i trigger the workflow by the other user, i get the "correct" error message, that he cannot edit this fields. But because of the setting "execute as owner", this shouldn't be the case...right? So i think, the "change" to the owner context is not happening.

In the event log, there is just this message, that the "other" user doesn't have the privilege to update entity and so on...

Can anybody reproduce this?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Restarting the service didn't solve it this time :(

Was this reply helpful? Yes No
Bojan.borisovski@ho... 480 on at

Like (0)

Report

Hi Christian,

A few things you could check:

1. Did you check if the owner of the workflow has privileges?

2. If you have "Workflow Log Retention" checked you should get a more detailed error message. You could find this i think in if you open the real-time workflow and go to the Process Session tab. This will only show any errors logged for this process. Please post the error message.

3. Have you tried with an async workflow?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Bojan,

1. Yes, the owner can execute this workflow without any errors.

2. See below (but no different information in that message)

3. I tried now, but surprisingly the same result.

I found a text regarding the workflow security context:

- A background workflow is executed in the security context of “the user who made changes to the record” when :

-- It is configured as an on-demand process

-- And is started by a user using a Run Workflow command

- A background workflow is executed in the security context of “the owner of the workflow” when started based on an event

- For real-time workflows you have the Execute As option to decide whether the workflow should run in the security context of the owner of the workflow or in the context of the user who made changes to the record.

So if i get this right, in my case (sync workflow), the kind of triggering (ondemand, child process etc.) shouldn't matter...!?

--------------- Error message:

Sync workflow failed with error message - Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: User with ID 9fd5b217-1a67-e311-80b9-00155d001001 does not have Update permissions for the tbs_decisionmakersales attribute in the tbs_leasingcontract entity. The tbs_leasingcontractid of the record is ff01686c-b410-e411-80cb-00155d001002Detail:

<OrganizationServiceFault xmlns:i="www.w3.org/.../XMLSchema-instance" xmlns="schemas.microsoft.com/.../Contracts">

<ErrorCode>-2147158777</ErrorCode>

<ErrorDetails xmlns:d2p1="schemas.datacontract.org/.../System.Collections.Generic">

<KeyValuePairOfstringanyType>

<d2p1:key>CallStack</d2p1:key>

<d2p1:value xmlns:d4p1="www.w3.org/.../XMLSchema" i:type="d4p1:string"> bei Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context)

bei Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context)

bei Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context)

bei Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context)

bei Microsoft.Crm.Extensibility.ExternalMessageDispatcher.ExecuteInternal(IInProcessOrganizationServiceFactory serviceFactory, IPlatformMessageDispatcherFactory dispatcherFactory, String messageName, String requestName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, ParameterCollection fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId, Guid transactionContextId, Int32 invocationSource, Nullable`1 requestId, Version endpointVersion)

bei Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, UserAuth userAuth, Guid targetUserId, OrganizationContext context, Boolean returnResponse, Boolean checkAdminMode)

bei Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode)

bei Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Update(Entity entity, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode)</d2p1:value>

</KeyValuePairOfstringanyType>

</ErrorDetails>

<Message>User with ID 9fd5b217-1a67-e311-80b9-00155d001001 does not have Update permissions for the tbs_decisionmakersales attribute in the tbs_leasingcontract entity. The tbs_leasingcontractid of the record is ff01686c-b410-e411-80cb-00155d001002</Message>

<Timestamp>2014-07-21T12:27:49.439896Z</Timestamp>

<InnerFault>

<ErrorCode>-2147158777</ErrorCode>

<ErrorDetails xmlns:d3p1="schemas.datacontract.org/.../System.Collections.Generic">

<KeyValuePairOfstringanyType>

<d3p1:key>CallStack</d3p1:key>

<d3p1:value xmlns:d5p1="www.w3.org/.../XMLSchema" i:type="d5p1:string"> bei Microsoft.Crm.BusinessEntities.SecurityLibrary.AccessAttributeUpdateCheck(BusinessEntity entity, ExecutionContext context)

bei Microsoft.Crm.BusinessEntities.BusinessProcessObject.PreUpdateEventHandler.Invoke(Object sender, ExtensionEventArgs e)

bei Microsoft.Crm.BusinessEntities.BusinessProcessObject.UpdateWithPipelineAndExtensions(IBusinessEntity entity, ExecutionContext context)</d3p1:value>

</KeyValuePairOfstringanyType>

</ErrorDetails>

<Message>User with ID 9fd5b217-1a67-e311-80b9-00155d001001 does not have Update permissions for the tbs_decisionmakersales attribute in the tbs_leasingcontract entity. The tbs_leasingcontractid of the record is ff01686c-b410-e411-80cb-00155d001002</Message>

<Timestamp>2014-07-21T12:27:49.439896Z</Timestamp>

<InnerFault i:nil="true" />

<TraceText i:nil="true" />

</InnerFault>

<TraceText i:nil="true" />

</OrganizationServiceFault>

bei System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary`2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)

bei System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary`2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)

bei Microsoft.Crm.Workflow.SynchronousRuntime.SynchronousWorkflowActivityHost.ExecuteWorkflowUsingInvoker(Activity workflow, ICommonWorkflowContext context)

bei Microsoft.Crm.Workflow.SynchronousRuntime.SynchronousWorkflowActivityHost.StartWorkflow(WorkflowActivationData activationData, ICommonWorkflowContext context)

, error code - -2147158777

Was this reply helpful? Yes No
Suggested answer

Bojan.borisovski@ho... 480 on at

Like (0)

Report

Yes, error is indeed straighforward. I am guessing that guid (9fd5b217-1a67-e311-80b9-00155d001001) is from the user that starts the workflow and not the workflow owner's. But you can still check.

You are right it shouldn't matter what kind of triggering the workflow has.

I would suggest you to try a few more things:

1. Check if the user guid in the error from which user it is (you probably did this already)

2. Check if the workflow owner has a security profile that can read and update the field value.

3. Try setting the update feature to the field, to yes on the security profile of the running user and see if it passes.

4. Try creating an new sync and async workflow from scratch.

(Make the first workflow disabled) The workflow should have scope Organization and the owner should have a security profile to be able to update the these fields. If the sync workflows doesn't, the async workflow should work by any means. With the async workflow you can check execution in the system jobs.

5. Last try again configuring security on these fields from start. :-(

If this does not help, it may be indeed a bug with the realtime workflows as its a new functionality in CRM.

You can file bugs to microsoft here:

connect.microsoft.com/.../accepting-bugs

Hope it helps.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Bojan,

Thx for your help again.

You're right, this guid is the workflow starting user and not the owner.

I did these points today and at least the deletion of field security (of course) did it... So now I just have to redesign my business process to make sure, that there still is some kind of security :( (Already did it...) Thx to MS for not doing what function name suggests...

Thx for your time!

Was this reply helpful? Yes No
Verified answer

Bojan.borisovski@ho... 480 on at

Like (0)

Report

Hi Christian,

I was thinking that you could try reconfiguring the security from start, maybe something was missed on the way...

But, if you still get the same error, you can make a workaround and do it with a plugin.

With plugin you should not get the error with the workflow, even if you keep field security. You will set it to run under Admin user and it should be fine.

Was this reply helpful? Yes No