I have workflow that updates entity record after checking condition. Everything works well. But... For example workflow's owner is User1 and i try to modify the record with User2. I thought field "Modified By" must have a value User2, but it has a value User1. Why?
Automatic workflows inside Dynamics CRM always run in the security context of the owner of the workflow.
In your case the owner of the workflow is User1, so it's right that the modifiedby field has User1 value.
To complete the answer, on-demand workflows run in the security context of the running user.
Related
So I am using Node/MongoDB (mongoose) to implement this feature.
What I need is the right solution for the following problem:
We have many Company(ies)
Each Company can create it's own Roles
Role is a set of predefined Permissions (like task.create, task.read, task.update, task.delete)
They can choose which Permissions are included in which Role
Company can create it's own Users, and assign them a Role
Lets say that company created 3 roles (the order matters):
Owner (always predefined, has all Permissions)
Team Leader
SuperAgent
Agent
Beside that, I also have Users in a tree structure, with parent reference which holds the _id of the User above him.
The rules are:
User can have none or many children
User cannot be above someone that have higher role than him
User cannot be below someone that have lower role than him
The Tree can get as deep as they want...
So the right representation of this would be:
But because Company Owner can at any time make new Role, or switch the order of roles, the problem occurs...
Let's say he switched the places of 2 roles, and they are now:
Agent
SuperAgent
How would you update all Users?
Also, what if he creates a new Role, puts it in 3rd place, and now needs to update everyone 1 role below, so he can attach that new role to a user...
What approach would you take to solve this kind of issue?
For multiline text fields in Azure DevOps work items, is it possible to add functionality that inserts the user name and a timestamp? Our old work tracking solution had a button labeled Stamp that performed this function but the lack of it in DevOps is causing some workflow and auditing issues. The information we need is part of the History for each work item, unfortunately it is not queryable data.
Something like this:
DeveloperLuke # 12/20/2018 9:01 AM
Solution XYZ deployed to ABC.Dev01
InfraLeia # 12/20/2018 10:35 AM
Solution XYZ failed to deploy to DEF.QA01 with error "Resource not responding. A34". Currently investigating.
I have a user performing a data import into Dynamics CRM. The partial error on the import says the user does not have enough privileges to access the Dynamics CRM Object for 2 lookup columns. One of them the user imported. The importer can see both the lookup list values. Can someone explain the proper permissions required for the user performing the data import?
You mentioned they can see, ie Read privilege. Check Write privilege as well.
Most importantly, Lookup attribute import needs AppendTo & Append privileges in respective entities.
When you are importing EntityA having EntityB lookup, importing User should have a security role with AppendTo in EntityA & Append in EntityB privileges + appropriate (user/BU level) access levels
Verify the AppendTo & Append privileges of those entities.
I assume you already verified these mentioned privileges.
Update:
Seems like custom Power user role (probably created from scratch) is throwing problems. Always start with cloning OOB security roles like salesperson & fill out the needed privileges. This helps to carry the hidden privileges.
Avoid giving highest privilege like Sys.Admin which will give users more than what needed, for ex. Bulk delete button will appear in Delete ribbon flyout & once my user configured Bulk delete job assuming record deletion action.
Atleast remove it once the import job is done.
Sorry if this is sort of confusing because I'm not sure how to word this. I am trying to create a workflow that runs off of Account's in Microsoft CRM 2011. One part of this workflow requires me to retrieve a field contained in the Business Unit of the User in the Account's "Created By" field. However, the workflow will only allow me to access the Business Unit itself, but not any of its fields.
I'm wondering if there is a simple trick or work-around that will allow me access to this data.
Thanks!
For reference, the Account has a User, who has a Business Unit, and the Business Unit has a field I need to access. CRM, however, doesn't want to let me get more than 2 levels deep when accessing fields.
Clunky but do-able if you accept a bit of denormalisation (temporarily or otherwise). I'll assume for the sake of example you want to get at the "cost centre" field from the BU.
Add a field on User entity to temporarily hold the value from the BU (so make it same type and length, text(100) in this case), optionally put it on the form.
Create a child workflow for the User entity to update the user with the "cost centre" value from their BU. Make it only available to run as a child, not onDemand or anything else. Activate
In your Account workflow, add a step to call the child workflow against the relevant user (eg Created By in your case).
Add a step to wait until the new cost centre field on the user record contains data.
Now do whatever you need to with the value from the user record, such as update the Account, or do some branched logic.
Whatever you do, once you have used the value, clear the field on the user record, or do this as the last step of the workflow.
Now, since Users don't change BU very often, you might actually just go ahead and keep that value on the User record permanently, and instead of a child workflow, simply run this on create of a new user, or on change of BU, and store the value permanently on the User record. Yes, it is 'denormalised' and not purest SQL design, but then you don't need a child workflow, you don't need a wait state and you don't have to clear the value at the end, or worry about what happens when two Accounts need to run their workflow at the same time. I include the more general approach above as this might apply to other records which do change their parent quite often.
Just an additional thought - you can access the "owning business unit" of the Account, but this will be the BU of the Owning User, rather than the Created By, but is your business process such that this would normally be the same person? (eg users only have Create priviledge to "user owned" depth, so can only create records they own).
If so, then you could get at the BU directly from the Account, and then any fields on it too (in a condition or to update the Account)
Alternative which is less ideal but a similar approach - add a relationship from Account to BU (eg "created BU"). Now you can update the Account with this by referring to the Created By User's BU, then in the next step, reference this value from the Account. This is again denormalised, and less preferable since number of Accounts is far greater than number of users, so the level of duplicate information is much higher.
You can't get deeper with the standard steps of a workflow.
The solution is to create a custom workflow activity, you can start from this article:
http://msdn.microsoft.com/en-us/library/gg328515.aspx
I am using the BusinessObjects Enterprise server and i have a report that uses the "department" as a parameter field to control the selection of records. there are 20 different departments.
I want to schedule this report to run 20 times with a new single department selected each time. Is there a way to do this without scheduling the report 20 times?
thanks for any help
Yes, you can. A bit of a process:
Create a Group for each department
Add users to groups as desired; ensure that they have an email address
Create a Profile; add a Profile Value for each Group (one Profile Value for each Group/Department ID combination); the Profile Values will be strings (important)
Create a Publication; add your report to the Source Document; add the Groups that you created earlier to the Enterprise-Recipient list
now define the Personalization (the key part of this); you can either add a Filter (set TABLE.FIELD or FORMULA to your Profile (Report Field & Enterprise Recipient Mapping columns) OR set the Department ID parameter to the appropriate Enterprise Recipient Mapping value (your parameter needs to be a string for this to work; note comment earlier).
set Destination to Email
set other properties (e.g. Format) as desired
Save & Close
You can also schedule this Publication to occur on a recurring basis.
Notes:
This solution uses the Publication Job Server (runs the Publication), the Crystal Reports Job Server (to run the report), the Adaptive Processing Server (does the bursting), and the Destination Job Server (send the email messages). You may want to create a separate set of these services and package them into their own server group, then force the Publications to use only this server group.
Related to the earlier point, you may want to create a server group just for scheduled reports and force recurring instances to use this server group. Why? Publications don't seem to do a good job of waiting for reports in a queue--if a Crystal Reports Job server isn't available, the Publication will fail. Forcing scheduled-report instances to generate on their own server group helps to eliminate this issue.
If you make significant changes to the report (e.g. add a parameter), you may need to remove then add the report to the Source-Document list to ensure that it has the most-recent definition; other changes to the report (e.g. adding a column) don't seem to require this attention. YOUR MILEAGE MAY VARY.
You can design the report with the department as a group.
Have a new page after each group and be sure to print the records from the department group section, not the details.
This is assuming you are getting all the departments inside your database fields.