Recently, Microsoft introduced the multi-entity/table lookup field which was one of the most awaited features. Previously it was only available for the OOB customer lookup field; for example, the customer field has contact and account for selection in the customer lookup field. In this release of Dynamics 365 CRM, it is now possible to create a lookup field that has a multi-entity/table. For example, for Retailer custom entity, we want to assign a Distributor and Distributor is lookup up field. Here, we want to assign Distributor to either Account, Contact or Lead entity. Earlier, in such cases we would have created three lookup fields with these entities and show/hide lookup field based on other options set field. But with recent release, it is now possible to create lookup field with multiple entities. So here we have created only one lookup field with Account, Contact and Lead entity. However, currently it can be done only programmatically but in the future it will be added to Microsoft UI.

Now, to create multi-entity/table lookup field we have written the below C# code. Here, we have created a Distributor lookup field with Account/Contact/Lead entities.

OrganizationRequest multiLookupOrgReq = null;
OneToManyRelationshipMetadata accountMetedata = null;
OneToManyRelationshipMetadata contactMetedata = null;
OneToManyRelationshipMetadata leadMetedata = null;
OrganizationResponse organizationResponse = null;

try
{
//create request object
multiLookupOrgReq = new OrganizationRequest();

// give lookup attribute information
multiLookupOrgReq.Parameters[“Lookup”] = new LookupAttributeMetadata()
{
SchemaName = “ikl_Distributor”,
DisplayName = new Label(“Distributor”, 1033)
};

//request name
multiLookupOrgReq.RequestName = “CreatePolymorphicLookupAttribute”;

//Create relationship objects
accountMetedata = new OneToManyRelationshipMetadata();
accountMetedata.ReferencedEntity = “account”;
accountMetedata.ReferencingEntity = “ikl_retailer”;
accountMetedata.SchemaName = “ikl_retailer_account”;

contactMetedata = new OneToManyRelationshipMetadata();
contactMetedata.ReferencedEntity = “contact”;
contactMetedata.ReferencingEntity = “ikl_retailer”;
contactMetedata.SchemaName = “ikl_retailer_contact”;

leadMetedata = new OneToManyRelationshipMetadata();
leadMetedata.ReferencedEntity = “lead”;
leadMetedata.ReferencingEntity = “ikl_retailer”;
leadMetedata.SchemaName = “ikl_retailer_lead”;

multiLookupOrgReq.Parameters[“OneToManyRelationships”] = new OneToManyRelationshipMetadata[]
{
accountMetedata,contactMetedata,leadMetedata
};

//execute request
organizationResponse = _service.Execute(multiLookupOrgReq);
}
catch (Exception ex)
{
throw new Exception(ex.Message);
}

And now when we execute the above code it will create lookup field with four entities as shown in the below screenshot:

Conclusion:  As illustrated above, by using multi-entity/table feature you can easily set value in the lookup field instead of creating multiple lookup fields.

Please follow Source

The post Multi-Entity/Table lookup in Dynamics 365 CRM appeared first on Microsoft Dynamics 365 Blog.

The Dynamics 365 Field Service schedule board allows users to manage bookings, resources, resource requirements, etc. Users can schedule their resource requirements by using simple drag and drop to a particular resource which creates Booking entity record. User can review the bookings on the schedule board as shown in the below screenshot.

Within the old UI of Schedule board, we were able to update the details being displayed on the Booking Template by changing the tab settings by navigating to specific Tab on the Schedule Board, and double on the tab as shown in the below screenshot

Now there is a new Schedule Board introduced which is Power Apps Component Framework i.e. PCF control with Unified Client Interface. We can enable the new schedule board interface by using “New Schedule Board” toggle button as shown in the below screenshot.

We noticed that currently, we cannot change the tab setting on the schedule board for a particular tab on New Schedule Board, but we can update the Schedule Board Setting entity record in order to update the Booking Template details.

For every tab created on the schedule board, there will have Schedule Board Setting entity record. So, navigate to the record with the same name as that of the Tab name on the Schedule Board. Please refer to the below screenshot for the same.

Therefore, in order to update the Booking Template Details on the Schedule Board we have to follow below mentioned steps.

1. As we know we can enable more than an entity for scheduling on the schedule board, so for each entity, we have enabled Booking Setup Metadata entity record as shown in the below screenshot.

2. On Schedule Board Setting entity record, we have to change the Settings from the Other tab in order to change the Booking Template details. Within the Settings, check for the Booking Setup Metadata Unique Identifier and change the “SlotTemplate” attribute data with the below-mentioned code within the JSON string. Save and Close the record.

3. Once the record is saved with updated changes, navigate to the New Schedule Board tab, which displays the Booking details based on the updated setting. Please refer to the below screenshot for the same.

Conclusion

In this way, we can customize the Booking Template details using the Schedule Board Setting entity record within Dynamics 365 Field Service.

Please follow Source

The post Customize Booking Template on Schedule Board with Dynamics 365 Field Service appeared first on Microsoft Dynamics 365 Blog.

Recently in our PCF control, we got the requirement that when the user selects a date from the calendar control then that date format should be of logged-in user. In this blog, we will check how to achieve the same.

Scenario:

Here is my current user settings in Dynamics 365 CRM.

As you can see here, the date format are as follows:

Short date: yyyy/MM/dd

Long date: MMMM,d,yyyy

In this example, I will be retrieving short date format.

Example

Here is the pop-up window in which I want to retrieve some basic user information including their joining date.

For Joining date field, I have used fabric UI datepicker control. Now when the user selects a date from datepicker like below then I want to set the date in the format of current logged-in user.

Get the Date Format

To get the logged-in user date format settings, I have retrieved dateFormattingInfo from PCF context object as below:

Context.userSettings.dateFormattingInfo.shortDatePattern. //For Short Date Format.

Context.userSettings.dateFormattingInfo.longDatePattern. //For Long Date Format.

Set the date in datepicker control

To set the retrieved date format to the datepicker control, I have used formatDate property of datepicker control.

Here is the function to set the user selected date:

Result

As you can see in the below image, I was able to set the date in logged-in user’s format(yyyy/MM/dd )

Conclusion

With the help of Context.userSettings.dateFormattingInfo.shortDatePattern, we can read and set date from logged-in user’s date format.

Please follow Source

The post How to Read and Set Date Format of Logged-in User in PCF Control appeared first on Microsoft Dynamics 365 Blog.

We recently had a requirement in Power Apps Partner Portal where the client specifically wanted Portal search option you see in the navigation bar to be seen and accessible ONLY for users who logs into the portal. With this, non-authenticated users will have no unauthorized access to CRM data visible in portal even via search.

As most of you all might know, the site setting titled “Search/Enabled” and setting the value as “false” COMPLETELY hide the Portal search option irrespective of whether you have logged into the portal or not. So that was not an option for us since we wanted to show the search option once the user has logged into the portal.

So, the next option we had in our mind was the typical way of using Web Page Access Control Rules. We did try adding the rules to the already existing system created web page “Search” as shown below:

“Search Page-Admin Access” was created for users with Administrator’s web role and the other one “Search Page-Non Admin Access” was created for users with Authenticated Users web role. Usually, this would make the page invisible if the user is not logged in. But in our case, though the search icon (as seen in the screenshot below) was still visible, but because we added the web page access control rules, when we tried to search something it automatically redirected to sign in page. This would ensure that you cannot see search results without logging to the portal.

Though this was half serving the purpose (i.e., users who have not logged in to the portal can’t use search functionality properly), our main motive of making the Search option NOT visible to whoever did not login to the portal was still an issue.

It’s in that situation after some research, we figured a solution for this problem.

1. Go to the Web Templates section and click on the template named “Header”.

2. Now search for “search” in the template as seen below:

3. Now add the below code:

{% if user %}

Just above the already present line written below:

{% assign search_enabled = settings[‘Search/Enabled’] | boolean | default:true %}

4. And also add the below code:

{% endif %}

Just above the already present line written below:

<li class=”divider-vertical” aria-hidden=”true”></li>

The whole code changes will look like this:

Basically, what we did is we are checking if any user details found for logged in users, then only display the search icon or else not. And this is how it’s reflected in portal as shown below and the search icon is hidden!!

And the search is visible once the user logs in to the portal as shown below:

Conclusion:

In this way, by editing the header template as explained above we can hide the portal search in the navigation bar from users who have not logged in to the portal.

Please follow Source

The post How to Hide Portal Search for Anonymous Users in PowerApps Portal appeared first on Microsoft Dynamics 365 Blog.

Microsoft Teams is fast becoming the communication and collaboration app for businesses, and some would even agree that they literally live on teams. This, therefore, makes sense to have notifications and updates sent out on Teams to receive quicker responses and updates rather than using the traditional channels of emails or requiring another app to receive these notifications.

In this article, we will explore the capabilities of the Power Automate Microsoft Teams connector to send out actionable messages. Messages that not only display details with a couple of buttons to approve or cancel but also allow the users to add fill in additional fields and submit.

Actionable messages can be easily designed using Adaptive Cards. As the name suggests, these cards adapt themselves to the look and feel of the host app. Microsoft Teams is one of the apps that Adaptive Cards support. It JSON for the template formatting. While JSON may sound non-citizen friendly, adaptive cards can easily be designed using the WYSIWYG designer available. Once you are done with the design, copy the card payload and paste it in your flow step and that’s it!

Since the focus of this article is on Adaptive cards and Teams, we are using the manual trigger in this example to invoke the flow and post the messages. In this example, there is a need for revising a quote with the customer requesting a price discount. A message will be sent to the Manager with the details of the existing quote and ask them to enter the new price that could be presented to the customer.

Since we are using a manual trigger, we will add the following inputs

Next, we will add the “Post an Adaptive Card to a Teams user and wait for a response” action from the Microsoft Teams connector to send the message to the manager for approval.

This action will post the message to a user in the chat window. We can also post the adaptive card to a Teams channel using the other action displayed in the screenshot above. We will also use this one in our example.

For this action, we need to primarily provide the user to whom the message needs to be sent and the card payload itself.

Before you begin editing the details of the action, make sure to rename the action to something simpler like “ApprovalCard1” in the screenshot above. To read the responses entered by the user we need to refer to this action in the later steps.

In this example, I have added the user email of the user who invoked the flow manually using the dynamic values

You can also provide direct email addresses as shown below

Moving to the Message section. Looking at the Key/Value pairs it is expecting, I thought we could define the key/value pairs here and then refer them in the Adaptive Card design to pass dynamic values to the card. But I did not succeed in identifying the syntax to be used to refer to these key/value pairs. Hence ignoring these for now.

Now click on the Create Adaptive Card button available. After saving the card, you will be shown the Edit button to make further changes to the card design.

This will present you with the in-place Adaptive Card WYSIWYG designer to drag and drop controls on the canvas and get started right away.

As you hover over the canvas, you will find individual controls highlighted. Lets delete most of them. Edit the Tell us about… text block and call it Quote Details

To add a table kind of layout I used the FactSet element from the designer and dropped it on the canvas.

In the properties bar to the right you again see a label/value pair that you can add for each of the details to be displayed in the table.

In our example we are displaying all the details that we requested as input in the flow.

To understand the expression to be entered for the value so that it refers to the flow inputs, we will go back to the Manual trigger and click peek code

Peek code shows you the key values for these input controls. It may seem that the key values would be same as Product, Quantity, Rate, and so on but that is not the case

We will need to refer to text_1, number, number_1 to read the values that were entered by the user to display them in the card.

The value for each of these in the factset would be

Quantity – @{triggerBody()[‘number’]}
Rate – @{triggerBody()[‘number_1’]}
…

Next, we also want to allow the Manager to enter a custom rate if they would like to offer something other than the requested rate.

For this will add an input control Input.Text to the canvas and a TextBlock element for the label. Arrange it as shown in the screenshot below

Make sure to set the Id of the Input.Text control as we will need to use that Id to refer back to the value entered by the user in our flow.

Next we add the Approve and Cancel button. Make sure to set the Id for both the controls. This will help us identify the choice made by the user from the Adaptive card and process action accordingly.

We are now done with the design. Click Save card on the ribbon to return back to the flow designer.

We are ready to test this out Enter the values for the input parameters and you will find the following message posted in the chat window of the selected user.

The manager can enter the approved rate and click approve or even click cancel to reject any price change request.

We will enter 9000 in the approved rate and click approve to complete the testing.

Go back to the flow execution of the test run and check the details received as outputs of the adaptive card action.

Within data, you will get all the input values accepted in the card as properties. The choice of button is available in the “submitActionId” property.

We will add a condition control to check the action selected. Note the results of the AdaptiveCard action is not available for direct selection through Dynamic content and will be referred through expressions as shown below

If it is approved,

we will post a message on the Teams channel using the other action “Post Adaptive card in a chat or channel”

Choose Flow bot to have messages posted through the bot. You can also post as user, in that case, the user set in the connection is used to post the message.

In this action you will notice that the Adaptive Card does not have the designer that was available in the earlier action. In this case we need to design the adaptive card and copy and paste the card payload here.

Navigate to the designer.

Place an image and set the url property to the location of the image on the web. Next, add a Rich TextBlock, this will allow us to format the words within the text block independent of the whole text.

This is what the inlines block looks like

To refer to the flow values we have added the flow expressions as before.

Copy the card payload from the designer and paste in the Adaptive Card field of the action. Make sure all the expressions appear formatted correctly there.

Test the flow again. Now when you approve, a message will also be posted on the teams channel as shown below

Adaptive Cards are a great way to present actionable messages right within the app without having the users to navigate outside the app for user input or approvals.

Please follow Source

The post Actionable messages in Microsoft Teams with Adaptive Cards using Power Automate Flows appeared first on Microsoft Dynamics 365 Blog.

Microsoft PowerApps Portals provide us the configuration surface which allows users to add forms to collect data in the portal without custom development. Web Template is a Power Apps entity (adx_webtemplate), included with Power Apps portals, that is used to store template source content. A web template will generally contain Liquid for dynamic content rendering and is the central entity used to integrate Liquid templates with the rest of the Power Apps portals system.

While the most common use cases for Web Templates will be to render HTML, rendering the entire response (by deselecting Use Website Header and Footer) gives you the option of rendering any text-based format you choose. This is where the MIME Type attribute of Web Template becomes relevant. When a Page Template that does not use the website header and footer is rendered, the HTTP response Content-Type header will be set to the MIME type of the associated Web Template. (text/HTML will be used if no MIME Type is provided.).

In this blog, we will see how we can create a Web Template with application/jsonMIME Type to get data using FetchXml and how we can retrieve that JSON data through Ajax request in the script.

Here, we will take the example of filtering Account lookup (which is rendered as a dropdown) based on different Relationship Types field value. So, to retrieve Account entity data we will configure JSON type Web Template and to get the data based on different Relationship Types field value we will require to pass specific Relationship Type to Web Template through query string parameter.

Below are the configurations steps required to retrieve data using JSON type Web Templates,

1. Configure Web Template with MIME Type = application/json. Then add FetchXml and code to generate JSON of retrieved data in Source field of the Web Template as per requirement. For reference find below screen clip,

Get Account JSON Web Template:

Below is the sample code to retrieve Account data using FetchXml and generate JSON of retrieved data which we have added in Source field of GetAccountJSON Web Template:

{% fetchxml accounts %}

<fetchversion=”1.0″output-format=”xml-platform”mapping=”logical”distinct=”false”>

<entityname=”account”>

<attributename=”name”/>

<attributename=”primarycontactid”/>

<attributename=”telephone1″/>

<attributename=”accountid”/>

<orderattribute=”name”descending=”false”/>

<filtertype=”and”>

<conditionattribute=”customertypecode”operator=”eq”value=”{{request.params[‘relationshiptype’]}}”/>

</filter>

</entity>

</fetch>

{% endfetchxml %}

{% if accounts.results.entities.size > 0 %}

{

“results”:

[

{% for account in accounts.results.entities %}

{

“name”:  “{{account.name}}“,

“id”: “{{account.accountid}}”

}

{% unless forloop.last %},{% endunless %}

{% endfor %}

]

}

{% else %}

No data found.

{% endif %}

In above sample code, {{request.params[‘relationshiptype’]}}is added to get relationship type from query string parameter. And in the same way, we can pass multiple parameters and use them in FetchXml.

2. Create Page Template record to get account JSON and then set GetAccountJSON web template in Web Template field of Page Template. Also, uncheck the Use Website Header and Footer checkbox of Page Template as shown below,

Get Account JSON Page Template:

3. After that create Web Page record and set Get Account JSON Page Template in Web Page as shown below. Also, the Partial URL will be useful to retrieve JSON.

Get Account JSON Web Page:

4. Create Entity Permission for the respective entity and add appropriate Web Role in that entity permission to be able to read the respective entity records. In this example, we will create entity permission for Account For reference find below screenshot,

Account Entity Permission:

After all the above configurations, we will be able to retrieve the data from JSON type Web Template using Ajax request in script code. So, we will add the below code in the Custom JavaScript section of Entity Form to retrieve Account data from JSON type Web Template and bind retrieved data in Account lookup,

Entity Form:

Code:

$(function () {

//Get account data

getAccountData();

//Execute on relationship type change

$(‘#new_relationshiptype’).change(function () {

try {

//Get account data

getAccountData();

} catch (e) {

console.log(“onChangeOfRelationshipType :: ” + e.message);

}

});

//Function to get account data

function getAccountData() {

var webTemplateURL = “”;

var relationshipType = “”;

var accountName = “”;

var accountId = “”;

var accountCollection = null;

try {

//get selected relationship type

relationshipType = $(“#new_relationshiptype”).val();

//Clear account field

$(“#parentcustomerid”).empty();

//Add empty option in the account dropdown

$(“#parentcustomerid”).append(‘<option value=”” label=” “></option>’);

//Validate relationship type

if (!isValid(relationshipType)) { return; }

//Web tempalte url to retrieve account url

webTemplateURL = “/getaccountjson/?relationshiptype=” + relationshipType + “”;

//Request to custom page to get account data in json format

accountCollection = getResponse(webTemplateURL);

//Validate account result

if (accountCollection.results.length > 0) {

//Check for each account from account collection

accountCollection.results.forEach(function (account) {

//Check for account name and account id from account collection

if (isValid(account.name) && isValid(account.id)) {

//Get account name

accountName = account.name;

//Get account id

accountId = account.id;

//Append options to account dropdown

$(“#parentcustomerid”).append(‘<option value=’ + accountId + ‘>’ + accountName + ‘</option>’);

}

});

}

} catch (e) {

console.log(“getAccountData :: ” + e.message);

}

}

//Function to execute ajax request

function getResponse(webTemplateURL) {

var response = null;

try {

$.ajax({

type: “GET”,

url: webTemplateURL,

dataType: “json”,

async: false

}).done(function (json) {

response = json;

});

} catch (e) {

console.log(“getResponse :: ” + e.message);

}

return response;

}

//Validate attributes

function isValid(attributes) {

try {

if (attributes != null&& attributes != undefined && attributes != “”) {

returntrue;

}

else {

returnfalse;

}

} catch (e) {

console.log(“isValid :: ” + e.message);

}

}

});

In above code, webTemplateURL = “/getaccountjson/?relationshiptype=” + relationshipType + “”;is the URL prepared to get account data and this URL getaccountjsonis nothing but the Partial URL added on Get Account JSON Web Page. Also, relationshiptype=” + relationshipType + “is added to pass Relationship Type as a query string parameter.

Note: Instead of Home parent page if you want to set any other parent page in Web Page of JSON page then you need to add Partial URL of Parent Page as well in Ajax request i.e. suppose in above example we select Profile page as a parent page instead of Homepage then the URL for Ajax request will be as below,

Get Account JSON Web Page:

Ajax request URL:

webTemplateURL = “/profile/getaccountjson/?relationshiptype=” + relationshipType + “”;

Now, on the portal side, we can see if Relationship Type is not selected then Accountfieldnot listing any account to select,

And, below is the screen clip with Relationship Type selected and filtered accounts listed in Account dropdown,

Conclusion

In this blog, we have seen how we can use JSON type Web Templates in Power Apps Portals.

Please follow Source

The post Use of JSON Type Web Templates in PowerApps Portals appeared first on Microsoft Dynamics 365 Blog.

Microsoft PowerApps Portals provides us the configuration surface which allows users to add forms to collect data in the portal without custom development. Entity Forms provides the ability to create, update and display CRM entities records and they are placed into webpages in the portal or used in conjunction with sub grids and entity lists to build out complete web applications.

Recently, we had a business requirement to create Account entity record from PowerApps Portals with Contact lookup selected and ‘on submit’ of Account record, redirect to Contact selected on newly created Account record. We can achieve this with the help of below On Success Settings configuring options of Entity Form,

1. On Success: This defines what will be the next step on successful submission of entity form. This field has below options and Display Success Message is the default one:
   • Display Success Message
   • Redirect
2. ‘or Web Page’: Set a Web Page from the current website on which user wants to redirect on successful submission.
3. Append Attribute Value to Query String Parameter Name: Name to give to the parameter that correlates to the attribute value on the target entity that gets appended to the Query String of the redirect URL.
4. Append Attribute Value to Query String Attribute Logical Name: Logical name of an attribute on the target entity to get the value to be appended to the Query String of the redirect URL.

To be able to create Account entity record from PowerApps Portals we need to do following configurations in portal

1. 1. Create new Entity Form for Account entity with Insert mode as shown below,
      Account entity form:
   2. Then create one Web Page to access the account entity form from portal as shown below,
      Account web page:
   3. After that configure the Link in Primary Navigation Web Link Set to access Account Web Page from Portal Navigation as shown below,
      Link in Primary Navigation Web Link Set:

      By doing the above configurations we can access the Create Account Form in the portal on Create Account navigation click as shown below,

      

   Below are the configurations which have done to navigate to Contact selected on newly created Account record on successful creation of Account record,

   1. 1. Configure another Entity Form which will be for Contact entity with below configurations,
         • Entity Name: Contact
         • Mode: Edit/ReadOnly
         • Record Source Type: Query String
         • Record ID Query String Parameter Name: id

         Contact entity form:

      2. Then create one Web Page as well for Contact entity and set the Contact entity form as shown below, Contact web page:
      3. After that go to Account Entity Form and add below configurations in On Success Settings,Configurations:
         • On Success: Redirect
         • or Web Page: Custom – Account Web Page
         • Append Attribute Value to Query String Parameter Name: id
         • Record ID Query String Parameter Name: id
         • Append Attribute Value to Query String Attribute Logical Name: primarycontactid

      In the above configurations,
      Custom – Account Web Page is a Web Page name that has Contact entity form set with Edit mode. And, id is Record ID Query String Parameter Name added on Contact entity form.

   2. Account entity form:
   3. 

      After all these configurations, once you navigate to Create Account navigation from the portal you will see the create form of account entity as per below screen clip,

   4. On portal side:

      And, on submit button click of the above form, it will redirect to Custom – Contact Web Page and will display details of selected contact selected in “Primary Contact” field of account form as shown in below screen clip,The navigation URL format will be as below,

      <portal url>/<partial url of web page>/?id=<selected contact record id>

      For example: <portal url>/customcontactwebpage/?id=6da0e5b9-88df-e311-b8e5-6c3be5a8b200

      On portal side:

      In a similar way, we can pass the value of any other field as well which is present on entity form as a query string parameter.

      Conclusion

   5. In this blog, we have seen how we can pass the field value from one page to another using query string parameter configurations of entity form.

Please follow Source

The post Pass Field Value from One Page to Another as Query String Parameter in Microsoft PowerApps Portals appeared first on Microsoft Dynamics 365 Blog.

In this blog, we will see how we can navigate to login page after once we logout from any page in Microsoft Portal.

Let’s look at the requirement where we want to provision the setup such as that the log-in page is redirected as soon the user logs out. Now, after logging again in the portal user is again redirected to the same page from where he logged out.

There are only 3 steps, which we need to be followed to cater the above requirement in our Dynamics 365 Portal.

Step 1

Go to the Web Template entity and search “header”.

Step 2

Open the record and find the logout section in source control.

Step 3

Update the href attribute of the anchor tag as below.

From: – href=”{% if homeurl%}/{{ homeurl }}{% endif %}{{ website.sign_out_url_substitution }}”

To: –

href=”/Account/Login/LogOff?returnUrl={{ website.sign_out_url_substitution }}”

We have just replaced the homeurl with /Account/Login/LogOff?returnUrl=

Conclusion

This is the most precise way to set the login page as default page after logout.

Please follow Source

The post Redirect to Login page always after logout in Dynamics 365 Portal appeared first on Microsoft Dynamics 365 Blog.

When user needs to display all the record using the “account” entity on the portal page then he can perform the retrieve operation by calling OData query using JavaScript.

Working

First we will create the entity list. On the entity list there is tab “OData” where we need to fill the information like “Entity Type Name”, “Entity Set Name”, select the view and enable the Odata feed as shown in the below screenshot:

Based on above configuration system we will generate Odata Based URL as https://<portalurl>/_odata/entity_set_name, now we can retrieve the data on other webpages as well as show in the below screenshot

Retrieve the data using Javascript:

We have created a button “Get Accounts” on the html as shown below in the screenshot.

On clicking the button we call the function retrieveAccount() JavaScript code shown below:

function retreiveAccount () {

var oDataUrl = “/_odata/AccountSet”;

var response = getResponse(oDataUrl);

var accounts = new Array();

accounts.push([“Sr. No.”, “Name”]);

if (response != null) {

$.each(response, function (index, responseVal) {

accounts.push([(index + 1), (responseVal.name.toString())]);

});

}

//Create a HTML Table element to show the data.

var table = document.createElement(“TABLE”);

table.border = “1”;

//Get the count of columns.

var columnCount = accounts[0].length;

//Add the header row.

var row = table.insertRow(-1);

for (var i = 0; i < columnCount; i++) {

var headerCell = document.createElement(“TH”);

headerCell.innerHTML = accounts[0][i];

row.appendChild(headerCell);

}

//Add the data rows.

for (var i = 1; i < accounts.length; i++) {

row = table.insertRow(-1);

for (var j = 0; j < columnCount; j++) {

var cell = row.insertCell(-1);

cell.innerHTML = accounts[i][j];

}

}

var dvTable = document.getElementById(“dvTable”);

dvTable.innerHTML = “”;

dvTable.appendChild(table);

}

function getResponse(oDataUrl) {

var response = null;

$.ajax({

type: “GET”,

url: oDataUrl,

dataType: “json”,

async: false

}).done(function (json) {

response = json.value;

});

return response;

}

Now data can be shown on the website as shown below in the screenshot:

Conclusion

User can perform the retrieve operation by calling OData query using JavaScript

Please follow Source

The post Retrieve Dynamics 365 CRM data in Portal by calling Odata using JavaScript appeared first on Microsoft Dynamics 365 Blog.

When developer need to use the js framework in the web. With the Dynamics 365 portal and liquid templates you can utilize the development approaches with those frameworks within your liquid templates.

Working:

Here I am taking example I will be using the angular js framework here. We will create the new web, to create the web template go to->Portals->Web Template. Click on the “+NEW” and name the template as “Sample-Angular” shown in the below screen shot:

Develop your angular logic in the source as shown below in the screenshot:

Then create the page template and web page to view your build logic data as shown in the below screenshot:

Then angular js is not working on the MS Portal as shown in the below screenshot:

{% raw %} which tells the liquid parser to basically ignore the tags it would normally look for when parsing and rendering liquid. This is necessary because liquid uses the same mustache brackets that the JavaScript frameworks uses. You can start and end the raw segments as much as you like so that you can mix your liquid functionality with the framework at the same time. {%raw%} and {%endraw%} tag is uses as shown in the below code:

{% raw %}

<div ng-app=””>

<p>Input something in the input box:</p>

<p>Name : <input type=”text” ng-model=”name” placeholder=”Enter name here”></p>

<h1>Hello {{name}}</h1>

</div>

{% endraw %}

Now your angular js will work properly as shown in the screenshot, according to our logic developed.

Conclusion:

This is how with Dynamics 365 portal and liquid templates user can utilize the development approaches with Angular JS frameworks within your liquid templates.

Please follow Source

The post Working with Angular JS framework in Dynamics CRM Portal appeared first on Microsoft Dynamics 365 Blog.