{"id":37452,"date":"2024-02-23T15:55:29","date_gmt":"2024-02-23T10:25:29","guid":{"rendered":"https:\/\/www.inogic.com\/blog\/?p=37452"},"modified":"2024-02-23T15:55:29","modified_gmt":"2024-02-23T10:25:29","slug":"how-to-configure-a-trigger-to-handle-both-get-and-post-requests-effectively-using-power-automate","status":"publish","type":"post","link":"https:\/\/www.inogic.com\/blog\/2024\/02\/how-to-configure-a-trigger-to-handle-both-get-and-post-requests-effectively-using-power-automate\/","title":{"rendered":"How to configure a trigger to handle both GET and POST requests effectively using Power Automate"},"content":{"rendered":"

I recently encountered a client requirement that necessitated handling both “GET<\/strong>” and “POST<\/strong>” HTTP requests. While Azure Function offers a straightforward solution for such scenarios, the concern was it should be handled within Dynamics CRM. Faced with these constraints, I explored alternatives that would allow us to meet the client’s needs within the preferred environment. Accommodating both “GET”<\/strong> and “POST” <\/strong>methods posed a unique challenge for our project.<\/p>\n

I needed one URL that would trigger on \u201cGET\u201d<\/strong> and \u201cPOST\u201d<\/strong> methods. Only one time it will trigger the \u201cGET\u201d<\/strong> method to validate logic and after that, it will call for the \u201cPOST\u201d <\/strong>method to process some response. Below is the approach that allowed us to fulfill the client’s requirements seamlessly.<\/p>\n

1. Create a solution in https:\/\/make.powerapps.com\/<\/a>where you have to add your Power Automate<\/a> (Ms Flow)<\/p>\n

\"Power<\/p>\n

2. In the solution click on the \u201cNew<\/strong>\u201d button & select Flow as shown in the below image. It will redirect you to the Power Automate (MS Flow) window as shown in the following image.<\/p>\n

\"Power<\/p>\n

\"Power<\/p>\n

3. Now we have to Search for the \u201cWhen an HTTP request is received<\/strong>\u201d Trigger point in our newly created Flow & from the search result select\u00a0\u201cWhen an HTTP request is received\u201d and select \u201cWho can trigger the flow\u201d <\/strong>from the dropdown as per your requirement configure “Who can trigger the flow” based on your needs. Set the method as “GET” and give your flow a name. Finally, click on \u201cSave\u201d to obtain the “HTTP POST URL”.<\/strong><\/p>\n

\"Power<\/p>\n

4. Once saved, you\u2019ll receive an HTTP POST URL<\/strong>, as illustrated in the image below. Now I am using this URL as the endpoint. This ensures that whenever it is triggered, your flow will also be triggered, regardless of whether the request is a “GET<\/strong>” or “POST<\/strong>“.<\/p>\n

\"Power<\/p>\n

5. Next, add the “Initialize Variable<\/strong>” action to create variables. It will store the data coming into the Body.<\/p>\n

\"Power<\/p>\n

6. When the \u201cGET<\/strong>\u201d method is called then Body will be blank, we will get a result from query string parameters however in the \u201cPOST<\/strong>\u201d method response will come in Body. So, to handle both scenarios I have added the condition to check If Data is null then it should move further and take query string parameters and return them in the response as well as update that Power Automate from the \u201cGET<\/strong>\u201d method to \u201cPOST<\/strong>\u201d else it will direct return the response.<\/p>\n

\"Power<\/p>\n

\"Power<\/p>\n

\"Power<\/p>\n

Whenever any Power Automate gets created those are stored in the \u201cworkflow<\/strong>\u201d entity. So, I tried to find my Power Automate using ODATA and I got its ID, name, and other details. It stores all Power Automate steps in one field \u201cclientdata<\/strong>\u201d in JSON format. So, to update from \u201cGET<\/strong>\u201d to \u201cPOST<\/strong>\u201d we need to follow the below steps.<\/p>\n

\"Power<\/p>\n

Now in Power Automate, we specified the table (entity) name as “Processes<\/strong>” which is the display name of the \u201cWorkflow<\/strong>\u201d entity, and entered the ID of our flow in the “Row ID<\/strong>” field. we also need to retrieve the method stored in the “clientdata<\/strong>” attribute column. Therefore, select “clientdata<\/strong>” in the “Select columns<\/strong>” option. Also, set the variable “RecordData<\/strong>” using the “Body<\/strong>” output of the “Get row by ID<\/strong>” action.<\/p>\n

\"Power<\/p>\n

7. Following this, use the “Compose<\/strong>” action, where the input will be modified by substituting “GET<\/strong>” with “POST<\/strong>” in the aforementioned JSON.<\/p>\n

\"Power<\/p>\n

8. The subsequent step involves parsing the JSON, which means converting the JSON string into an object format. It\u2019s essential to input the correct schema, as illustrated in the image provided.<\/p>\n

\"Power<\/p>\n

9. The final step involves updating the previously retrieved process record. Modify the “clientdata<\/strong>” column to reflect the updated \u201cclientdata\u201d, wherein the method has been changed to “POST<\/strong>“.<\/p>\n

\"Power<\/p>\n

10. After the record is updated, the modified JSON will resemble the image below.<\/p>\n

\"Power<\/h2>\n

Conclusion<\/h2>\n

In conclusion, the method outlined above demonstrates how you can dynamically alter the flow’s method from “GET” to “POST”. This is particularly useful when there’s a requirement for your flow to be triggered once using the “GET” method and subsequently, for all future triggers, to operate using the “POST” method.<\/p>\n

\"\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

I recently encountered a client requirement that necessitated handling both “GET” and “POST” HTTP requests. While Azure Function offers a straightforward solution for such scenarios, the concern was it should be handled within Dynamics CRM. Faced with these constraints, I explored alternatives that would allow us to meet the client’s needs within the preferred environment.\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":11,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[36,1985],"tags":[2068],"class_list":["post-37452","post","type-post","status-publish","format-standard","hentry","category-microsoft-flow","category-power-automate","tag-and-power-automate-flows"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/37452","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/comments?post=37452"}],"version-history":[{"count":0,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/37452\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/media?parent=37452"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/categories?post=37452"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/tags?post=37452"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}