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.
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.
I am trying to make a field optional in the Dynamics CRM
The name of the entity is Case and the internal name of the field is customerid
When I try to change it from mandatory to optional, I get the below error message
You can not complete this action for this component because of the
configuration of its managed properties.
this is happening in Dynamics CRM online
I'm pretty sure you won't be able to.
It's one of the few fields where mandatory behaviour is enforced at the platform level, whilst most mandatory fields are enforced only on the user interface.
If I remember correctly, tring to create a case without a customer via the API will result in an exception.
Looking at the managed properties for the customerid field on my recently provisioned CRM Online, shows that I'm unable to change the requirement level - I don't even get the option for setting it as optional.
I wanted to remove the field from the form, but I was not able to do it from the UI
So I used XRMToolBox.
There is a plugin called as FormXML Manager, enable it in the XRMToolBox and load the entities. Once this is done you can remove the required field and publish the form
The question is the following:
I have a custom Requester field in TFS work items. It contains a valid TFS user name.
Is it possible to send an email to the person specified in this custom field, when the item changes a state?
In other words:
Requester = [Me]
Send email on State change
From the following questions :
1) “[Me]” variable for custom field alerts in TFS 2013
2) How to create custom Field with transition workflow in TFS
I figured out that custom fields (such as Requester) do not have = and <> operators. They have only Change, Change to, Change from. Thus it is not possible. (You can only observe the changes made to the custom fields)
Has anybody seen, herd or implemented a solution to this? Maybe a custom plug-in?
Thank You in advance!
You're looking at a server side event handler to achieve this.
Intercept the Work Item changed event
Check if the change was a
change in state
If it is, then email the address listed in the
Requester field.
There are couple of old projects on codeplex which should get you up and running but you'll need to update for TFS 2015 (and test with any updates you apply later)
Email alerts for TFS
TFS Work Item Watcher
There is a feature that just popped into VSTS that makes this a little slicker
Follow a Work Item
Although you would get notified on all changes rather than just state change
The feature was added in TFS "15" (not the same as TFS2015, see Brian Harry's blog post)
The feature is not enabled publicly yet, but there is a feature flag that you can turn on by changing a value in the team foundation registry to enable it - because it's not public yet you will have to contact Microsoft for instructions,
I have provided my email in the blog post
https://blogs.msdn.microsoft.com/rihamselim/2016/09/07/enabling-alerts-for-custom-fields-in-work-item-alerts/
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