Liquid error: Value cannot be null.
Parameter name: key
Microsoft Dynamics 365
This is not yet a released feature and there seems to have been some confusion incorrectly stating it as a functionality that has already been worked on.
This will continue to be an idea we will explore further.
Lots of complaints from my users about loss of tracking functionality from previous Outlook Tracker versus new UI Dynamics 365 App for Outlook
You can do this with a process in the meantime. Multiple required, or one if you're looking to alter all at once.
New field in work order : Update task percent
New field in work order
Simple Two options Yes/No
Name: Update % Complete
For ALL At Once
Entity: Work order Service Task
Work Order Service Task | % Complete | Contains Data
Work Order | Update % Complete | equals | yes
Work order Service Task
Right Pane - > Operator : Set to
Look For: Work Order
Field : Update task percent
Click on % Complete and press OK
Same here. I've already spent days in finding and implementing different work arounds for this behaviour. Several of our customers were not happy with it. Could be so easy...
I would go further than this.
I'd like to see when you create a template, you specify the primary entity the template is focused on, and then the relationship to the Contact that should be the recipient.
Email processing is then based on the primary entity, allowing you to navigate up and down to include related information in the email.
You could then use it for transactional emails on the Event Registration record for event based emails, navigating down to get event details, or up to get the list of sessions the Event Registration covered.
But this then goes to cover Emails regarding any record which features a contact lookup (most of the emails we ever want to send are to a Contact regarding something), not just limited to Events.
Certain organizations will not approve Microsoft Teams as a secure and viable solution. Currently the only alternative for members of those organizations is to @mention a huge number of users in every single post (including all replies) they make. It ultimately dissuades users from embracing Dynamics as a solution because generic e-mails remain significantly more efficient for larger teams. This is a bigger enabler than the votes indicate.
Excellent idea. Every single project I've been on that utilized the AWMS always complains about these orphan shipments/loads and always asks if there is a cleanup function to deal with them. 👍
This is especially important since we are urged to break up monolithic apps into smaller ones. Imagine having apps neatly broken up, ending up with two apps A and B, and one for the interplay (such as adding a B field to an A table) that is depending on them both: AB. Now if you're exposing the data of these apps via APIs, and you want to support A and B to be used both independently (which is the idea of having them separated) and combined (with the AB app on top of them), you would need API pages for A tables and for B tables, but as soon as you want to expose the B field that is added to the A table, you would also need to create an exact copy of the API page for the A table with just one B field added to it. That doesn't make sense.
If only we could
- add new fields to an API page, or
- allow extensions with the same prefix to extend API pages, or
- in some other way allow another extension to extend an API page