Microsoft recently introduced us to the Custom API feature which is a new way of creating custom actions in Dynamics 365 CRM as seen in our previous blog. However, while writing the previous blog, there wasn’t any way of using this custom API in workflows.

But recently, we did see an approach to make use of the custom API with workflows.

Now let’s see how to achieve this.

For demonstration purpose, we are creating a custom API that will be used in a workflow which will be triggered on creation of an account record. And every time this workflow gets triggered, it’ll call the custom API created by us, which will create a Phone Call activity associated to the same account with the due date set as the next day.

Step 1: Go to your solution in the power platform, click on ‘New’ and select the Custom API.

Step 2: A system form for Custom API will open up. Fill up the information about custom API.

Unique Name: Unique name for the Custom API. This will be shown in the Perform Action step in the workflow, so keep it easily identifiable.

Binding Type: Binding Type is an option set field and could be set as Global, Entity, and Entity Collection. Here, we have set it to Entity, because we need to bind this API to the account entity.

Bound Entity Logical Name: Here we need to put the logical name of the entity if we set Binding type as Entity.

Note:-Since we want to retrieve the account record in context of which the workflow was fired, we are setting Binding type to Entity & Bound Entity logical Name to account so that we will be able to pass that as the target to our plugin called in the custom API.

Enabled for Workflow: It is a Boolean type field, in which we set if we want to allow this custom API to be used in workflow steps or not. We are setting it to true since we want to use it in the workflow step.

Note:- This is the important field which plays the key role in making use of the custom API with workflows, which was not made available earlier but now it can very much be seen on the custom API form.

 Plugin Type: As explained in our previous blog as well, this is the lookup type of field which shall hold the already registered Plug-in assembly that is responsible for creation of phone call activity. Thus, it is advisable to first write and register your plug-in in CRM before starting with the custom API. If you are new to Plug-ins, then you can follow the steps from here.

From the next steps, we shall see how to use the custom API created in the above steps in workflow.

Step 3: Navigate to Advanced Settings -> Processes -> Create on New.

Step 4: After filling up the information in the dialog box, click on Ok.

Step 5: Click on Add Step -> Select Perform Action.

Step 6: Select the custom API that we have created before. Note that the Entity will be automatically selected as Accounts. Click on Set Properties.

Step 7: Select Account -> Account in ‘Look for’ and click on Add and then on Ok. It should look similar to this.

Step 8: Activate the process.

Step 9: Create an Account record. And a phone call activity record will get created associated to the account with the due date as the next day and thus can be seen in the Timeline as well.

Conclusion: This is how we can use the Enabled for Workflow feature of custom API to use custom API in a workflow step.

Please visit the Source and support them

The post How to use a custom API as a step in Dynamics 365 CRM Workflows appeared first on Microsoft Dynamics 365 Blog.

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.

In this blog, we will see how to read the parameter from the URL in Power Automate.

For example, let’s take the below URL:

https://inogic.com?EmpId=1&EmpName=JohnThomas

Here, we have passed Employee Id and Employee Name in the web URL and now we have to get those two parameters from URL. There is one inbuilt function in Power Automate i.e. uriQuery() which will help you to read those two parameters from URL.

To explore this function, we created one Power Automate flow which will get triggered on creation of CRM entity record. In that,  initialize one variable and assign above URL to that variable as shown in the below screenshot:

After creating URL variable, we passed this variable to the uriQuery() function using Data Operation as shown in below screenshot:

Given below is the expression that we have used in the above step:

uriQuery(variables(‘URL’))

After running the above Power Automate flow, we will get the expected output i.e., URL parameter will be separated from URL as shown in the below screenshot:

Conclusion

In this way, by using uriQuery() function we can easily retrieve the parameters from URL in Power Automate flow.

Please Follow the Source

The post How to Read URL Parameters from URL using uriQuery() function in Power Automate 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.

In this blog, we will see how we can sort records in the dataset in PCF control. The dataset object does have the property “sorting” which we can use to sort records according to a particular column in ascending or descending order.

To keep dataset designing simple and easy to understand we will be using the React Fluent UI framework’s “DetailList-Basic” control in our example. You can also use simple HTML, Javascript, and CSS for dataset grid as per the design.

As we are using DetailList, the ‘onColumnClick’ event has parameter that represents the column which is clicked. On this event, we can write the below code:

// when a column header is clicked sort the items
const _onColumnClick = (ev?: React.MouseEvent, column?: any): void => {
let dataset = props.pcfContext.parameters.sampleDataSet;
const newValue: any = {
name: column.fieldName,
sortDirection: column.isSortedDescending ? 0 : 1
}
while (dataset.sorting.length > 0) {
dataset.sorting.pop();
}
dataset.sorting.push(newValue);
(dataset.paging as any).loadExactPage(1);
dataset.refresh();
let isSortedDescending = !column?.isSortedDescending;
setItems(dataset.sorting);
setColumns(
columns.map(col => {
col.isSorted = col.key === column?.key;
col.isSortedDescending = isSortedDescending;
return col;
})
);
}

In the above code, we first need to get the current sorting direction of the selected column after which we can change it in the opposite direction. For example, if the current direction is ‘ascending’ then we will change it into ‘descending’ and vice versa. For that, we need to check dataset.sorting. To change the current SortStatus of the dataset column, we have to pass the object that contains the name (the name of the column) and sortDirection (the current sort direction of the column).

SORTDIRECTION

After changing the SortStatus, we need to call dataset.refresh(), otherwise, there will be no desired effect.

Also, we have to navigate to the first page if we want that sorting to be applied to the entire dataset instead of applied only for dataset visible on the same page.

dataset.sorting.push(newValue);
(dataset.paging as any).loadExactPage(1);
dataset.refresh();

Conclusion

By using Sorting, we can easily sort records in the PCF control dataset for a particular column in ascending/descending order.

Go to Source and hit them a thumps up

The post How to Sort Dataset in PCF Control? 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.