So I need to essentially create a PowerApp which would make appointments in Dynamics CRM. All data gets sent to CRM - except the case regarding the appointment.
Originally, I was using the normal SubmitForm() but switched over to the Patch() function. I have set the _regardingobjectid_value to a valid case GUID. The problem lies with _regardingobjectid_type - as for some reason, I cannot set the entity name. In this case, the entity name would be "incident", but it keeps throwing an error that states that it needs another GUID. I really don't know what to do anymore.
This is the code I am using:
Patch(
Appointments;
Defaults(Appointments);
{
Subject: txtSubject.Text;
'Start Time': DateTimeValue(_selectedStartTime);
'End Time': DateTimeValue(_selectedEndTime);
Description:txtDescription.Text;
_regardingobjectid_value: _regarding;
_regardingobjectid_type: incident
}
)
So to clarify, I would just really like to have my appointment have the specified case regarded to it.
At the moment I am getting an error stating that incident "name is invalid". If I remove the type, I get an ambigious error. And when I set the case id to the type, it does input my record into Dynamics, however with no case (understandably so).
This should work. Exact same problem is solved in this blog post.
You have to make sure to set this Use GUID data types instead of strings setting in App settings.
Patch(
Appointments;
Defaults(Appointments);
{
Subject: txtSubject.Text;
'Start Time': DateTimeValue(_selectedStartTime);
'End Time': DateTimeValue(_selectedEndTime);
Description:txtDescription.Text;
_regardingobjectid_value: GUID(_regarding);
_regardingobjectid_type: “incidents”
}
)
Edit:
Nick mentioned in his blog about this. Should be a known bug.
The only reason why I choose Flow as opposed to writing directly to
CDS from the PowerApp is that at this point you cannot set the
“regarding” when you write to a task in the Canvas based PowerApp, but
you can using Flow.
Related
We call the microsoft exchange to set the extended property which in our case is an unique guid
microsoft.exchange.webservices.data.core.exception.service.remote.ServiceResponseException: An internal server error occurred. The operation failed., Invalid named property
Its been working great until now when some of our users are facing the above issue ....
val uId = getUniqueId();
val emailExtendedPropDef = new ExtendedPropertyDefinition(uId,"uniqueId", MapiPropertyType.String)
try {
email.setExtendedProperty(emailExtendedPropDef, uId.toString)
email.sendAndSaveCopy()
} catch {
case e: Exception =>
error(s"Exception in setting extended property for user $from", e)
throw e
}
trying to find the root cause of the issue, we are also thinking it might be related to throttling on Microsoft exchange for extended properties (Not sure how to prove if it's indeed throttling) any help to point us in the right direction will be of great help
Our use case is to able to retrieve the email when customer want's to reply back we want to retrieve that particular email to be included in users reply....currently we are using the uid to achieve that ....
we have been using the code as per the documentation here
https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd633654(v%3Dexchg.80)
and also the documentation here
https://github.com/OfficeDev/ews-java-api/wiki/Getting-Started-Guide#extended-properties
Update : As per the comments we do understand that we have to treat extendedProperty as a column definition and update the same column ...but we couldn't figure out how to achieve this as...Any code samples to point us in the right direction will be of great help
Latest Update : We have deleted some of the extendedPropertyDefinition's but still facing the same invalid property could some one please point us in the right direction
Is it safe to say that getUniqueId returns a different guid on each call? If so, then that is the problem. Think of the Guid for an extended prop as a namespace. The exchange store limits the number of custom extended props to something like 32k per mailbox. So you are likely hitting that limit. But aside from that, the main reason for creating an extended property is so that you can refer to it later. But if you are basically discarding the namespace each time, you are leaving orphaned props on items. Without understanding your particular scenario, I can only say that the Guid should be thought of truly as a namespace. Choose one for your app/company/scenario and hard code it. They create all the named props you want within that namespace. For instance, "MyProp/String" in Guid namespace 1 is a different property than "MyProp/String" in Guid namespace 2.
Breeze's default validation messages use the database field name as part of the displayed error message; such as, "EmpTeleNo is required". Obviously, this probably shouldn't end up in the production version of our software.
But as we approach delivery of our software, it was hoped that this might be fixed, perhaps by inspecting the "Display" attribute from the model or something like that. As far as I can tell, this issue still remains.
Has this problem been resolved or has anyone figured out a work-around?
Thanks.
This is not YET well documented but you can simply set the 'displayName' property on any dataProperty and this will override the autogenerated display name and will be used for all validation messages for this property. So
var custType = myEntityManager.metadataStore.getEntityType("Customer");
var dp = custType.getProperty("companyName");
dp.displayName = "My custom display name";
Also, see the "Customize the message templates" topic at the bottom of this page: http://www.breezejs.com/documentation/validation.
There is also an item on the Breeze User Voice that requests something very similar to what you are asking for. Please vote for it.
https://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions
I've added several Subjects under the Admin section of Dynamics CRM. I'd really like to add one of these "Subjects" to the Regarding field within an Activity. E.g. someone called, and it was related to "ProductX".
Strangely, the entity type "Subject" does not appear when trying to select an item for the field. A range of other entity types such as "Contacts" and "Accounts" appear.
Does anyone know why Subjects can't be selected here? I would have expected this was OOB functionality.
That because it doesn’t really make sense to have activities regarding a subject.
An activity only really makes sense in the context of something else, and that something else is generally a real thing in the world or a piece of work. The Regarding field really says: "This Activity involves working on this thing".
For example, if John Smith rings your company, it makes sense to create a new Phone Call activity that Regards the Contact record of John Smith. With this approach you can see the entire activity history against a Contact. By making the Phone Call regard the Contact you are saying this piece of work is about the Contact.
If the Phone Call was Regarding a Subject, it would be saying, "This Phone Call involves working on the Subject", which isn’t true, its work about the Contact. Also you lose the ability to track correspondence with the contact.
So my suggestion would be, use the Regarding field to link to people and things, and add a relationship between your activities and subject if you want to classify your phone calls.
As a side, there is a product entity in CRM (it can’t be Regarding however), so perhaps you should create a relationship to that.
I have a problem, which I'm really trying to figure out how I could best solve this. I have read various posts regarding this error and seems you can avoid this by using JavaScript by using:
Xrm.Page.getAttribute("name").setSubmitMode("always");
which doesn't work for me or inside the plugin. Now to my problem, I have an update plugin firing on my incident form, which updates some fields. However when I try to resolve the case or cancel it I get the error from my update plugin "The object cannot be updated because it is read-only" I have tried the following and would appreciate if somone could advice me what I'm doing wrong. My code for a plugin I'm registering as SetState on pre-operation against the incident form:
SetStateRequest setState = new SetStateRequest();
setState.EntityMoniker = new EntityReference();
setState.EntityMoniker.Id = incidentId; //Id which needs to be resolved/canceld
setState.EntityMoniker.Name = "statecode";
setState.EntityMoniker.LogicalName = "incident";
setState.State = new OptionSetValue();
setState.Status = new OptionSetValue();
SetStateResponse setStateResponse = (SetStateResponse)service.Execute(setState); }
On the state and status I'm quite confused to what value I have to set it to. I'm just getting an error when my incident is on Active and I'm trying to resolve and cancel the case. I would appreciate if someone could help me out here. Thanks in advance.
I think there are a few areas of confusion in your post...
Xrm.Page.getAttribute("name").setSubmitMode("always");
This is clientside code and will never have any bearing on the behaviour of your (serverside) plugin. It merely forces an attribute on the form to be submitted whether it has changed or not, during a save. If the record is in a read-only state, it will not change that fact.
I'm not at all clear what you are trying to acheive in your code. You mention that an update plugin is failing; you have posted code which would attempt to set the state of the incident to something (as #glosrob suggests, you are not providing any values in the OptionSetValue objects for State and Status so as you might already know, the code you have posted is invalid); you then state that you have registered your plugin on the SetState request. This means that it would fire if the user tries to set the state of the incident. Given that your code is itself trying to set the status of the incident, I'm not sure that it makes sense...
It sounds like what you want to do is, on update of an incident, set certain values. If the incident is in a read-only state, make it readable first, and then update the values. Do you then need to restore the state of the entity to it's former state? It sounds awkward and might perhaps suggest that there is a better way to meet your core requirement.
Maybe start with what you are trying to achieve and we can work from there :)
You should remove
setState.EntityMoniker.Name = "statecode";
from your code. This field Name has other purpose.
Also, you should add
setState.State.Value = 1;
setState.Status.Value = -1;
I have a form that I have users fill out and then it gets e-mailed to me.
I am trying to get an example of how I would create an ID (based on my own conventions) that I can use to keep track of responses (and send back to the user so they can reference it later).
This is the convention I am striving for:
[YEAR]-[SERVICE CODE]-[DATE(MMDD)]-[TIME]
For example: "2012-ABC-0204-1344". I figured to add the TIME convention in the instance that two different users pick the same service on the same date rather than try to figure out how to only apply it IF two users picked the same service on the same date.
So, the scenario is that after the user goes through my wizards inputting their information and then click "Submit" that this unique ID would be created and attached to the model. Maybe something like #Model.UniqueID so that in an e-mail response I send to the user it shows up and says "Reference this ID for any future communication".
Thanks for any advice/help/examples.
In your post action
[HttpPost]
public ActionResult Create(YourModel model)
{
model.UniqueId = GenerateUniqueId(serviceCode);
}
public string GenerateUniqueId(string serviceCode)
{
return string.Format("{0}-{1}-{2}", DateTime.Now.Year, serviceCode, Guid.NewGuid().ToString().Replace("-",""); //remove dashes so its fits into your convention
}
but this seems as I'm missing part of your question. If you really want unique, use a Guid. This is what we've used in the past to give to customers - a guid or a portion of one. IF you use a portion of one ensure you have logic to handle a duplicate key. You don't need to worry about this though if using a full guid. If the idea is just to give to a customer then ignore the rest of the data and just use a guid, since it can easily be looked up in the database.