I just started at a company that uses MS Dynamics CRM 2016 extensively and I've been trying to run down a comprehensive answer for how the system handles tasks/cases that have been assigned to employees within my company after those employees have left the company.
It's apparently quite a large problem because the tasks/cases have been explained to me as "falling into the void" and being unfindable once the owner (ex-employee) no longer has access. Is this true?
Is there a way to confidently query all tasks/cases for employees that no longer have access if I 1) don't have a good idea of who those employees might be and 2) don't have a full list of what might have been assigned to them?
I'm still very new to MS Dynamics CRM and am not even sure where to start. I know it's possible to run queries, advanced finds, and searches. Those in my company that have explained to me the situation seem to have tried some form of these methods so far.
Any and all help is greatly appreciated. Thanks!
You should prepare the list of CRM users who left the company (if not query the disabled users and identify them), then do a house keeping by reassigning their records by going to their user profile. Read more
Related
Is any clean way to hide an area from the sitemap, other than reviewing many role privileges one by one and remove privilege completely. I would be ok with amount of work just that there is no one-to-one correlation between the privilege and the menu item and more important, is the fact some of the privileges has many ramifications and I don't want to affect existing functionality. It would be hard to track bugs in this case.
This has to start with the logical grouping of necessary working entities (SubArea) under right Group, and ideally hence the main Area.
Let's say for example - Sales area should have Managers and Reps as Groups then classify the sub-areas for them individually for their needed entities. Then the navigation can be regulated with the help of identifying privileges specific for each persona and the navigation items can be controlled which hide the Group from others. Read more
Or if it is tough to identify such dedicated persona privilege, then create a dummy entity just for sitemap regulation without breaking any existing implementation.
In UCI app world, you can spin a new App for each persona, so silo app with own sitemap and logical groups the way you want.
We use CRM 4.0 at our institution and have no plans to upgrade presently as we've spend the last year and a half customising and extending the CRM to work with our processes.
A tiny part of model is a simply hierarchy, we have a group of learning rooms that has a one-to-many relationship with another entity that describes the courses available for that learning room.
Another entity has a list of all potential and enrolled students who have expressed an interest in whichever course.
That bit's all straightforward and works pretty well and is modelled into 3 custom entities.
Now, we've got an Admin application that reads the rooms and then wants to show the courses for that room, but only where there are enrolled students.
In SQL this is simplified to:
SELECT DISTINCT r.CourseName, r.OtherInformation
FROM Rooms r
INNER JOIN Students S
ON S.CourseId = r.CourseId
WHERE r.RoomId = #RoomId
And this indeed is very close to the eventual SQL that CRM generates.
We use a Crm QueryEntity, a Filter and a LinkEntity to represent this same structure.
The problem now is that the CRM normalizes the a customize entity into a Base Table which has the standard CRM entity data that all share, and then an ExtensionBase Table which has our customisations. To Give a flattened access to this, it creates a view that merges both tables.
This view is what is used by the Generated SQL.
Now the base tables have indices but the view doesn't.
The problem we have is that all we want to do is return Courses where the inner join is satisfied, it's enough to prove there are entries and CRM makes it SELECT DISTINCT, so we only get one item back for Room.
At first this worked perfectly well, but now we have thousands of queries, it takes well over 30 seconds and of course causes a timeout in anything but SMS.
I'm given to believe that we can create and alter indices on tables in CRM and that's not considered to be an unsupported modification; but what about Views ?
I know that if we alter an entity then its views are recreated, which would of course make us redo our indices when this happens.
Is there any way to hint to CRM4.0 that we want a specific index in place ?
Another source recommends that where you get problems like this, then it's best to bring data closer together, but this isn't something I'd feel comfortable in trying to engineer into our solution.
I had considered putting a new entity in that only has RoomId, CourseId and Enrolment Count in to it, but that smacks of being incredibly hacky too; After all, an index would resolve the need to duplicate this data and have some kind of trigger that updates the data after every student operation.
Lastly, whilst I know we're stuck on CRM4 at the moment, is this the kind of thing that we could expect to have resolved in CRM2011 ? It would certainly add more weight to the upgrading this 5 year old product argument.
Since views are "dynamic" (conceptually, their contents are generated on-the-fly from the base tables every time they are used), they typically can't be indexed. However, SQL Server does support something called an "indexed view". You need to create a unique clustered index on the view, and the query analyzer should be able to use it to speed up your join.
Someone asked a similar question here and I see no conclusive answer. The cited concerns from Microsoft are Referential Integrity (a non-issue here) and Upgrade complications. You mention the unsupported option of adding the view and managing it over upgrades and entity changes. That is an option, as unsupported and hackish as it is, it should work.
FetchXml does have aggregation but the query execution plans still uses the views: here is the SQL generated from a simple select count from incident:
'select
top 5000 COUNT(*) as "rowcount"
, MAX("__AggLimitExceededFlag__") as "__AggregateLimitExceeded__" from (select top 50001 case when ROW_NUMBER() over(order by (SELECT 1)) > 50000 then 1 else 0 end as "__AggLimitExceededFlag__" from Incident as "incident0" ...
I dont see a supported solution for your problem.
If you are building an outside admin app and you are hosting CRM 4 on-premise you could go directly to the database for your query bypassing the CRM API. Not supported but would allow you to solve the problem.
I'm going to add this as a potential answer although I don't believe its a sustainable or indeed valid long-term solution.
After analysing the indexes that CRM had defined automatically, I realised that selecting more information in my query would be enough to fulfil the column requirements of an Index and now the query runs in less then a second.
In my application my users can generate statements, monthly and weekly. I've recently been
asked to allow the users the capability to associate a customer with either weekly or monthly
but not both, to a customer. This then leads to...if a user selects a weekly customer and runs a monthly
statement, he or she, should be prompted that customer's statement cannot be generated and why.
My question: In the UI of the customer screen when editing a customer, should I label the choice option(s) as
Select the customer Statement
Frequency [ monthly or weekly]?
Select the customer Statement Type [
monthly or weekly]?
What giudelines do you follow to assist you when making such decisions?
Thanks
I would suggest using Statement Frequency. Other choices might be cycle or period.
The rule of thumb should be to ask the user (product's business owner) what terms and wordings to use. It's not uncommon for business users to review all the terms and messages the application uses. That way the resulting product will speak the users' language.
The reason is that developer-invented terminology often leads to unintuitive UI. It may be perceived as clumsy, unfamiliar, or even incomprehensible by end-users. The worst case is bringing the software's internal terminology and mechanisms to the user interface.
Hi Sitepoint wizard people,
Say we have an admin application that has multiple users and various objects. What I'd like to do is control access within the object itself - that is, it will behave one way for one type of user, and another way for other users. For example...
Director Mike can override Reception user Sally's registration date. One would assume that Mike could set any date both in the past or in the future. Then we have Payroll user Steve who can also modify Sally's registration date, but only for dates in the past up until (for example) one year ago. To spice things up, then we have the HR Manager Mary who can also amend Sally's registration date, but only for dates from precisely 23rd June 2007 up until one month from now...
How can I program the access restrictions so that on the front end, the form control is restricted with a min and max date, and in the backend, the validator checks the entered date to make sure it falls between those dates? I'd obviously need to be able to tweak the min and max dates for each user type. Other objects might have different parameters - maximum amount on a discount field or days of the week for overtime, for example.
I've asked this question in different ways, but each time I get bogged down by the implementation. I'm currently developing it as a php/MySQL web-based application, but thoughts and comments from other platforms very welcome! This time I'm looking at first principles, so it doesn't matter what your background is, if you have any ideas, please let me know! What do you even call this type of access control...?
Depending of how you application is based, you could ask for credentials at the start of the application and depending on who is requiring access, you could load a different xml file containing different settings.
As for security issue, make sure that the different xml files can't be reached by the users.
Edit:
Since you are using MySQL you could do something like this.
Let's say you have a table of users that has those fields : UserId, UserName, RestrictionId.
And with a Restriction table that looks like : RestrictionId, FieldName, FieldCondition.
This way, in your php app, when a user is authenticated, you can go fetch the correct "Restrictions" on the field and apply them in your code. If it happens that you have multiple fields that require different rules then you can simply add them with the correct RestrictionId.
This DB design is far from perfect, I'm pretty sure you can do better
Since, you are already using MySql db. You can maintain the UserRole Master table details in DB itself. Load the user role data based on login, then you can easily validate the changes made by the user accordingly.
I have a web application that syncs Outlook contacts to a database (and back) via CDO. The DB contains every contact only once (at least theoretically, of course doublets happen), providing a single point of change for a contact, regardless of how many users have that particular contact in Outlook (like Interaction or similar products).
The sync process is not automatic, but user-initialized. An arbitrary timespan can pass before users decide to sync their contacts. A subset of these contacts may have been updated by other users in the meantime.
Generally, this runs fine, but I have never been able to solve this fundamental problem:
How do I doubtlessly identify a contact object in a mailbox?
I can't rely on PR_ENTRYID, this
property changes on contact move or
mailbox move.
I can't rely on my own IDs (e.g. DB
table ID), because these get copied
with the contact.
I absolutely can't rely on fields
like name or e-mail address, they
are subject to changes and updates.
Currently I use a combination of 1 (preferred) and 2 (fall-back). But inevitably, sometimes users run into the problem of synching to the wrong contact because there is none with a given PR_ENTRYID, but two with the same DB ID, of which the wrong one is chosen.
There are a bunch of Outlook-synching products out there, so I guess the problem must be solvable.
I had a similar problem to overcome with an internal outlook plugin that does contact syncing. I ended up sticking a database id in the Outlook object and referring to that when doing syncs.
The difference here is that our system has a bunch of duplicates that get resolved later by the users. When they get merged I'll remove the old records and update outlook with all of the new information along with a new id.
You could do fuzzy matching to identify duplicates, but duplicate resolution is a funny problem that's mostly trial and error. We've been successful at implementing "fuzzy" matching logic using the levenshtein distance algorithm for names and addresses cleaned down to a hash code.
Good luck, my syncing experiences have been somewhat painful.