In my organization, "Set whether reassigned records are shared with the original owner" is enabled and I want to prevent this behavior on specific entity.
But problem is that no "GrantAccess" message throws when the record shares!
I can't detect this sharing event and as a result, unable to prevent this default behavior.
I have solved my issue with hooking a plugin to Update event and on Post-Operation I will revoke the shared access created.
I want to know what Message will be thrown in this situation, if no messages will be thrown, why this is?
Also I will appreciate if somebody has some better solutions for what I want.
Related
I have recently started to use Google Analytics 4 for event tracking, using Google Tag Manager to send events to Analytics. I have set up the custom variables in Tag Manager as well as in GA4.
Everything seems to work very well in Tag Manager's debug mode, and also if I look up the events in real-time view I get the requested event along with all the parameters I have set in Tag Manager. However, once I look up the events for the last couple of days in the Engagement -> Event view, a couple of my parameters are missing, and also I'm not getting the same hit count for each parameter, even though each event has all parameters set:
As you can see, 86 events have been recorded, but the event count for the parameters widely varies.
Here's a screenshot of my Tag manager settings:
I have tried to set up a new event with the same parameters, but (logically) I got the same result. I am under the strong impression I'm missing something obvious here. Does anyone have experience with this, or has anyone come across this same issue?
To be honest, you can just try to click on mark as conversion in the Events tab, and this should save them. I think for some reason GA4 doesn't save parameters otherwise...
i cant get this til work with fields and parameters for an event so i try to create a user custom dimension instead and also to send it as a content group and as user property
also i can see the user id under app instance for the standard report user explorer
but i can't filter on or select this one myself
i cant create the custom parameter reports like gerrit did
but yeah create them as custom dimensions /metric first should be the way
ga4 has a bug when you edit a standard report, you add 3 card and deselect one it still thinks you are maxed out and you have to start over...
the test internal users filters dont work, though you can see data in debug and under events, but since i know they work i know try to just make the filters active
I have written code that is supposed to help us automate some specific cases. It will create a addresstag for the customer and change the status of the case to "Address Tag Sent".
All this works as intended, but for some reason the status of the case is changed back to "New".
As you can see here there is an event called "Activate" that changes the status.
I haven't found what this event is or why it occurs. I have gone through all the Workflows we got, all processes, all code (As good as I can) and spent a good amount of time trying to google it but I still come out empty handed.
Is there someone who might know what this event is? Or maybe got any idea how to access/modify it?
'Activate' will essentially re-activate any record and put the statuscode back to the default statuscode\status reason - I am guessing your default is set to 'New'.
I would investigate in these directions:
Since “changed by” showing as “CRM migration account”, this maybe an ETL job like SSIS, or Scribe which is syncing data changes from outside integration
Maybe the same service account is used by plugin, to reset the StateCode and StatusCode on some business logic
Is there some Business process flow stages available in your form, as I see “Service stage” attribute in audit before that, there may be logics coupled with that
Verify the dependencies of statecode attribute in customizations to see any SDK steps or workflows referencing that. Check in your code repos and check with any long timers in your project for any business logics implemented in the past.
We have an addin that saves additional data back into the email which is causing conflicts when office 365 processes the email and 'returns' the sent copy back to the mailbox.
We have identified that saving the information back to the email after exchange has received a copy to process the message is what causes the issue but we don't know how to solve this. Does anyone have any advice how to go about modifying the UserProperties values without causing conflicts?
Do not save the message twice - set the data before it is saved for the very first time. Or keep your custom data elsewhere - associated (hidden) content table is the standard location.
It is not possible to avoid adding custom data to items in Outlook. But the best what you can do is to avoid weak places that could cause such issues.
I have a simple plugin for a custom entity that is set to trigger on Update of my custom entity. It is registered in the Post Operation stage. I have noticed some strange behaviour when I make changes to the Owner field of the record in addition to other standard fields (e.g. text boxes, dates etc).
The plugin fires the first time and the only attributes that come across in the image are all the regular fields. The owner field does not come across.
The plugin then fires again, but the Depth property of the context is still only one (i.e. the plugin is not getting triggered by changes made in the plugin code). In this run of the plugin, the attribute that come across is only the Owner field.
My theory is that because the owner fields are 'special', the CRM is doing two different requests - one to change the regular fields, and then another request for changing the owner via an AssignRequest. However, I cannot find any 'official' documentation for this behaviour.
Can someone explain why this is happening?
I am running Dynamcs CRM 2013 UR2
The Update event fires during the Assign event. So if an assignment takes place your plug-in will execute. The same is true for SetState - if you activate/deactivate a record an Update event takes place. These items are not documented in the SDK.
A good practice is to use Attribute Filtering on your Update plugin so it only fires for the fields it is concerned about - this will, assuming it is isn't looking at the owner related fields, avoid it firing twice. If you have logic specific to record ownership you would put it in a plugin that is registered on the Assign event.
I was not able to find official documentation about this, but I think Assign message is what you are looking for (if the entity is user-owned. See http://msdn.microsoft.com/en-us/library/gg328576.aspx. I would strongly recommend that you specify Filtering Attributes if you are registering a plugin on Update message. You could also debug your plugin and inspect MessageName property of plugin context and see what message gets triggered. I hope this helps.
I understand that a plugin registered for pre-validation executes outside of the database transaction but I'm not sure I can think of a scenario when this would be preferable to pre-operation. Can someone give me an example of where pre-validation registration might be useful?
We have a few plugins registered on the 'PreValidation' event although this is on premise, not online.
I did not write these specific plugins myself but I can describe one and give the justification for using 'PreValidation' rather than 'PreOperation'.
Entity: Account
Event: Delete
Logic: Plugin runs pre validation. Checks that there are no contacts referencing any of the account's addresses. If any are found, stop execution. If not, delete account.
e.g.
Account 'Stackoverflow' has address 'Jeff Attwood's House' and Contact 'glosrob'. 'glosrob' is referencing 'Jeff Attwood's House' through a customisation. If a user selects to delete 'StackOverflow', we should detect 'glosrob' is referencing an address and prevent the delete.
The reasoning behind this was the developer found that at the PreOperation stage, some aspects of the delete had already happened, namely the cascade deletes. The logic of the plugin requires us to check all contacts - by registering at PreOperation, contacts under the account had already been deleted, rendering the check obsolete.
In our previous scenario, when the user selected to delete 'StackOverflow' Account, the Contact 'glosrob' would be deleted before the plugin runs. Therefore when the plugin did run afterwards, it would allow the delete.
As with most things in CRM, it all comes down to requirements and solutions, but I think that gives you an idea of why/when you might use a PreValidation stage. We have a few others with similar reasoning that run on the 'Delete' event.
I know its very old post, came here while digging for an answer for the same question...
Later I found one key point from MSDN on the same topic and i thought it would be helpful If I post the infromation over here for all..
The Prevalidation plugin would happen prior to the security checks. For ex: If an account is "VIP" account and you dont want this account record to be deleted (no matter even he is a super user/admin), then this better can happen in pre validation. Because at that time you are not really bothered about who the user is and what sort of permissions he has (even he may not have any permissions to delete any records in the system), CRM will go and check the database for the user's security roles during the pre operation and that is where the first database hit would happen.. before that it self, we can stop the exucution of the plugin based on our validation rules..
I hope that make sense...
Thank you
Regards
Srikanth