by Contributed | Jan 26, 2024 | Technology
This article is contributed. See the original author and article here.
Web application firewalls (WAFs) are essential tools for cyber security professionals who want to protect their web applications from malicious attacks. WAFs can filter, monitor, and block web traffic based on predefined as well as custom rules. Custom rules allow you to create your own unique rule that is evaluated for each request that passes through the WAF. These rules hold higher priority than rules in the managed rulesets and will be processed first. One of the most powerful features of Azure Web Application Firewall is the ability to create geomatch custom rules, which allow you to match web requests based on the geographic location of the source IP address. You may want to block requests from certain countries or regions that are known to be sources of malicious activity, or you may want to allow requests from specific locations that are part of your business operations. Geomatch custom rules can also help you comply with data sovereignty and privacy regulations, by restricting access to your web applications based on the location of the data subjects.
In this blog post, we will introduce you to the geomatch custom rules feature of Azure Web Application Firewall and show you how to create and manage them using the Azure portal, Bicep and PowerShell.
Geomatch Custom Rule Patterns
Geomatch custom rules can help you achieve various security objectives, such as blocking requests from high-risk regions and allowing requests from trusted locations. Geomatch custom rules can also be very useful for mitigating distributed denial-of-service (DDoS) attacks, which aim to overwhelm your web application with a large volume of requests from multiple sources. By using geomatch custom rules, you can quickly identify and block the regions that are generating the most DDoS traffic, while allowing legitimate users to access your web application. In this blog, we’ll cover different custom rule patterns that you can use to tune your Azure WAF using geomatch custom rules.
Scenario: Block traffic from all countries except “x”
One of the common scenarios where geomatch custom rules can be very helpful is when you want to block traffic from all countries except a specific one. For example, if your web application is only intended for users in the United States, you can create a geomatch custom rule that blocks all requests that do not originate from the US. This way, you can reduce the attack surface of your web application and prevent unauthorized access from other regions. This specific technique uses a negating condition for this traffic pattern to work. To create a geomatch custom rule that blocks traffic from all countries except the US, check out the Portal, Bicep, and PowerShell examples below:
Portal example – Application Gateway:
Portal example – Front Door:
*Note: You’ll notice on the Azure Front Door WAF, we are using SocketAddr as the Match variable and not RemoteAddr. The RemoteAddr variable is the original client IP that’s usually sent via the X-Forwarded-For request header. The SocketAddr variable is the source IP address the WAF sees.
Bicep example – Application Gateway:
properties: {
customRules: [
{
name: ‘GeoRule1’
priority: 10
ruleType: ‘MatchRule’
action: ‘Block’
matchConditions: [
{
matchVariables: [
{
variableName: ‘RemoteAddr’
}
]
operator: ‘GeoMatch’
negationConditon: true
matchValues: [
‘US’
]
transforms: []
}
]
state: ‘Enabled’
}
Bicep example – FrontDoor:
properties: {
customRules: {
rules: [
{
name: ‘GeoRule1’
enabledState: ‘Enabled’
priority: 10
ruleType: ‘MatchRule’
matchConditions: [
{
matchVariable: ‘SocketAddr’
operator: ‘GeoMatch’
negateCondition: true
matchValue: [
‘US’
]
transforms: []
}
]
action: ‘Block’
}
PowerShell example – Application Gateway:
$RGname = “rg-waf “
$policyName = “waf-pol”
$variable = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable -Operator GeoMatch -MatchValue “US” -NegationCondition $true
$rule = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule1 -Priority 10 -RuleType MatchRule -MatchCondition $condition -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
PowerShell example – FrontDoor:
$RGname = “rg-waf”
$policyName = “wafafdpol”
$matchCondition = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue “US” -NegateCondition $true
$customRuleObject = New-AzFrontDoorWafCustomRuleObject -Name “GeoRule1” -RuleType MatchRule -MatchCondition $matchCondition -Action Block -Priority 10
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject
Scenario: Block traffic from all countries except “x” and “y” that target the URI “foo” or “bar”
Another scenario where geomatch custom rules can be useful is when you want to block traffic from all countries except two or more specific ones, that target an explicit URI. For example, if your web application has specific URI paths that are only intended for users in the US and Canada, you can create a geomatch custom rule that blocks all requests that do not originate from either of these countries. With this pattern, request payloads from the US and Canada are still processed through the managed rulesets, catching any unwanted malicious attacks while still blocking requests from all other countries. This way, you can ensure that only your target audience can access your web application and avoid unwanted traffic from other regions. Furthermore, to reduce potential false positives, you can include the country code “ZZ” in the list to capture IP addresses that aren’t yet mapped to a country in Azure’s dataset. This specific technique also uses a negate condition for the Geo location type and a non-negate condition for our URI match. To create a geomatch custom rule that blocks traffic from all countries except the US and Canada to a specified URI, check out the Portal, Bicep, and PowerShell examples below:
Portal example – Application Gateway:
Portal example – Front Door:
Bicep example – Application Gateway:
properties: {
customRules: [
{
name: ‘GeoRule2’
priority: 11
ruleType: ‘MatchRule’
action: ‘Block’
matchConditions: [
{
matchVariables: [
{
variableName: ‘RemoteAddr’
}
]
operator: ‘GeoMatch’
negationConditon: true
matchValues: [
‘US’
‘CA’
]
transforms: []
}
{
matchVariables: [
{
variableName: ‘RequestUri’
}
]
operator: ‘Contains’
negationConditon: false
matchValues: [
‘/foo’
‘/bar’
]
transforms: []
}
]
state: ‘Enabled’
}
Bicep example – FrontDoor:
properties: {
customRules: {
rules: [
{
name: ‘GeoRule2’
enabledState: ‘Enabled’
priority: 11
ruleType: ‘MatchRule’
matchConditions: [
{
matchVariable: ‘SocketAddr’
operator: ‘GeoMatch’
negateCondition: true
matchValue: [
‘US’
‘CA’
]
transforms: []
}
{
matchVariable: ‘RequestUri’
operator: ‘Contains’
negateCondition: false
matchValue: [
‘/foo’
‘/bar’
]
transforms: []
}
]
action: ‘Block’
}
PowerShell example – Application Gateway:
$RGname = “rg-waf “
$policyName = “waf-pol”
$variable1a = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition1a = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1a -Operator GeoMatch -MatchValue @(“US”, “CA”) -NegationCondition $true
$variable1b = New-AzApplicationGatewayFirewallMatchVariable -VariableName RequestUri
$condition1b = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1b -Operator Contains -MatchValue @(“/foo”, “/bar”) -NegationCondition $false
$rule1 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule2 -Priority 11 -RuleType MatchRule -MatchCondition $condition1a, $condition1b -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule1)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
PowerShell example – FrontDoor:
$RGname = “rg-waf”
$policyName = “wafafdpol”
$matchCondition1a = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue @(“US”, “CA”) -NegateCondition $true
$matchCondition1b = New-AzFrontDoorWafMatchConditionObject -MatchVariable RequestUri -OperatorProperty Contains -MatchValue @(“/foo”, “/bar”) -NegateCondition $false
$customRuleObject1 = New-AzFrontDoorWafCustomRuleObject -Name “GeoRule2” -RuleType MatchRule -MatchCondition $matchCondition1a, $matchCondition1b -Action Block -Priority 11
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject1
Scenario: Block traffic specifically from country “x”
A similar scenario where geomatch custom rules can be helpful is when you want to block traffic from a specific country or multiple countries. For example, if your web application is facing a lot of malicious requests from country X, you can create a geomatch custom rule that blocks all requests that originate from that country. This way, you can protect your web application from potential attacks and reduce the load on your resources. You can use this pattern to block multiple countries that you have validated as malicious or hostile. This specific technique uses a match condition for this traffic pattern to work. To create a geomatch custom rule that blocks traffic from country X, check out the Portal, Bicep, and PowerShell examples below:
Portal example – Application Gateway:
Portal example – Front Door:
Bicep example – Application Gateway:
properties: {
customRules: [
{
name: ‘GeoRule3’
priority: 12
ruleType: ‘MatchRule’
action: ‘Block’
matchConditions: [
{
matchVariables: [
{
variableName: ‘RemoteAddr’
}
]
operator: ‘GeoMatch’
negationConditon: false
matchValues: [
‘US’
]
transforms: []
}
]
state: ‘Enabled’
}
Bicep example – FrontDoor:
properties: {
customRules: {
rules: [
{
name: ‘GeoRule3’
enabledState: ‘Enabled’
priority: 12
ruleType: ‘MatchRule’
matchConditions: [
{
matchVariable: ‘SocketAddr’
operator: ‘GeoMatch’
negateCondition: false
matchValue: [
‘US’
]
transforms: []
}
]
action: ‘Block’
}
PowerShell example – Application Gateway:
$RGname = “rg-waf “
$policyName = “waf-pol”
$variable2 = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition2 = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable2 -Operator GeoMatch -MatchValue “US” -NegationCondition $false
$rule2 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule3 -Priority 12 -RuleType MatchRule -MatchCondition $condition2 -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule2)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
PowerShell example – FrontDoor:
$RGname = “rg-waf”
$policyName = “wafafdpol”
$matchCondition2 = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue “US” -NegateCondition $false
$customRuleObject2 = New-AzFrontDoorWafCustomRuleObject -Name “GeoRule3” -RuleType MatchRule -MatchCondition $matchCondition2 -Action Block -Priority 12
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject2
Geomatch custom rules and Priority
When using geomatch custom rules, it’s important to use the priority parameter wisely to avoid unnecessary processing or conflicts. The Azure WAF will determine the order that it evaluates the rules by using the priority parameter. This parameter is a numerical value that ranges from 1 to 100, with lower values indicating higher priority. The priority must be unique across all custom rules. You should assign higher priority to the rules that are more critical or specific for your web application security, and lower priority to the rules that are less essential or general. This way, you can ensure that WAF applies the most appropriate actions to your web traffic. Given our examples above, the scenario where we’ve identified an explicit URI path is the most specific and should have a higher priority rule than other types of patterns. This allows us to protect a critical path on the application with the highest priority while allowing more generic traffic to be evaluated across the other custom rules or managed rulesets.
Geomatch Custom Rule Anti-Patterns
On the other hand, there are some anti-patterns that you should avoid when using geomatch custom rules. These are scenarios where you set the custom rule action to allow instead of block. This can have unintended consequences, such as allowing a lot of traffic to bypass the WAF and potentially exposing your web application to other threats. Instead of using an allow action, you should use a block action with a negate condition, as shown in the previous patterns. This way, you can ensure that only traffic from the countries that you want is allowed, and all other traffic is blocked by the WAF.
Scenario: Allow traffic from country “x”
The first anti-pattern that you should be aware of is setting the geomatch custom rule to allow traffic from a specific country. For example, suppose you want to allow traffic from the United States because you have a large customer base there. You might think that creating a custom rule with the action “allow” and the value “United States” would achieve this. However, this is not the case. What this rule does is to allow all traffic that originates from the United States, regardless of whether it has a malicious payload or not, as the allow action bypasses further rule processing of the managed rulesets. Additionally, traffic from all other countries will still be allowed to be processed by the WAF, consuming resources. This exposes your web application to malicious requests from the United States that would otherwise be blocked by the WAF.
Portal example – Application Gateway:
Portal example – Front Door
Bicep example – Application Gateway:
properties: {
customRules: [
{
name: ‘GeoRule4’
priority: 20
ruleType: ‘MatchRule’
action: ‘Allow’
matchConditions: [
{
matchVariables: [
{
variableName: ‘RemoteAddr’
}
]
operator: ‘GeoMatch’
negationConditon: false
matchValues: [
‘US’
]
transforms: []
}
]
state: ‘Enabled’
}
Bicep example – FrontDoor:
properties: {
customRules: {
rules: [
{
name: ‘GeoRule4’
enabledState: ‘Enabled’
priority: 20
ruleType: ‘MatchRule’
matchConditions: [
{
matchVariable: ‘SocketAddr’
operator: ‘GeoMatch’
negateCondition: false
matchValue: [
‘US’
]
transforms: []
}
]
action: ‘Allow’
}
PowerShell example – Application Gateway:
$RGname = “rg-waf”
$policyName = “waf-pol”
$variable3 = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition3 = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable3 -Operator GeoMatch -MatchValue “US” -NegationCondition $false
$rule3 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule4 -Priority 20 -RuleType MatchRule -MatchCondition $condition3 -Action Allow
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule3)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
PowerShell example – FrontDoor:
$RGname = “rg-waf”
$policyName = “wafafdpol”
$matchCondition3 = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue “US” -NegateCondition $false
$customRuleObject3 = New-AzFrontDoorWafCustomRuleObject -Name “GeoRule4” -RuleType MatchRule -MatchCondition $matchCondition3 -Action Allow -Priority 20
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject3
Scenario: Allow traffic from all counties except “x”
Another anti-pattern that you should avoid when using geomatch custom rules is to set the rule action to allow and specify a list of countries to exclude. For example, you might want to allow traffic from all countries except the United State, where the US is a country that you suspect of malicious activity. However, this approach can also have unintended consequences, such as allowing traffic from countries that you have not verified or validated as safe or legitimate or allowing traffic from countries that have low or no security standards, exposing your web application to potential vulnerabilities or attacks. As mentioned in the previous scenario, using the allow action for all countries except the US, indicates to the WAF to stop processing the request payloads against the managed rulesets. All rule evaluation will cease once the custom rule with allow is processed, thus exposing the application to unwanted malicious attacks.
Therefore, it is better to use a more restrictive and specific rule action, such as block, and specify a list of countries to allow with a negate condition. This way, you can ensure that only traffic from trusted and verified sources can access your web application, while blocking any suspicious or unwanted traffic.
Portal example – Application Gateway:
Portal example – Front Door:
Bicep example – Application Gateway:
properties: {
customRules: [
{
name: ‘GeoRule5’
priority: 21
ruleType: ‘MatchRule’
action: ‘Allow’
matchConditions: [
{
matchVariables: [
{
variableName: ‘RemoteAddr’
}
]
operator: ‘GeoMatch’
negationConditon: true
matchValues: [
‘US’
]
transforms: []
}
]
state: ‘Enabled’
}
Bicep example – FrontDoor:
properties: {
customRules: {
rules: [
{
name: ‘GeoRule5’
enabledState: ‘Enabled’
priority: 21
ruleType: ‘MatchRule’
matchConditions: [
{
matchVariable: ‘SocketAddr’
operator: ‘GeoMatch’
negateCondition: true
matchValue: [
‘US’
]
transforms: []
}
]
action: ‘Allow’
}
PowerShell example – Application Gateway:
$RGname = “rg-waf”
$policyName = “waf-pol”
$variable4 = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition4 = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable4 -Operator GeoMatch -MatchValue “US” -NegationCondition $true
$rule4 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule5 -Priority 21 -RuleType MatchRule -MatchCondition $condition4 -Action Allow
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule4)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
PowerShell example – FrontDoor:
$RGname = “rg-waf”
$policyName = “wafafdpol”
$matchCondition4 = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue “US” -NegateCondition $true
$customRuleObject4 = New-AzFrontDoorWafCustomRuleObject -Name “GeoRule5” -RuleType MatchRule -MatchCondition $matchCondition4 -Action Allow -Priority 10
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject4
Conclusion
The Azure Web Application Firewall is a powerful tool for protecting your web applications from common threats and attacks and by using geomatch custom rules, you can fine-tune your security controls based on the geographic location of the requests. The patterns outlined help to maintain the effectiveness and performance of the Azure WAF when utilizing geomatch custom rules. You should always test your rules before applying them to production and monitor their performance and impact regularly. By following these best practices, you can leverage the power of geomatch custom rules to enhance your web application security.
Resources
What is Azure Web Application Firewall on Azure Application Gateway? – Azure Web Application Firewall | Microsoft Learn
Azure Web Application Firewall (WAF) v2 custom rules on Application Gateway | Microsoft Learn
Azure Web Application Firewall (WAF) Geomatch custom rules | Microsoft Learn
What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn
Web application firewall custom rule for Azure Front Door | Microsoft Learn
Geo-filtering on a domain for Azure Front Door | Microsoft Learn
Configure v2 custom rules using PowerShell – Azure Web Application Firewall | Microsoft Learn
Create and use v2 custom rules – Azure Web Application Firewall | Microsoft Learn
Configure an IP restriction WAF rule for Azure Front Door | Microsoft Learn
by Contributed | Jan 25, 2024 | Dynamics 365, Microsoft 365, Technology
This article is contributed. See the original author and article here.
On January 25, 2024, we published the 2024 release wave 1 plans for Microsoft Dynamics 365 and Microsoft Power Platform, a compilation of new capabilities planned to be released between April 2024 and September 2024. This first release wave of the year offers hundreds of new features and improvements, showcasing our ongoing commitment to fueling digital transformation for both our customers and partners.
This release reinforces our dedication to developing applications and experiences that contribute value to roles by dismantling barriers between data, insights, and individuals. This wave introduces diverse enhancements across various business applications, emphasizing improved user experiences, productivity, innovative app development and automation, and advanced AI capabilities. Watch a summary of the release highlights.
Explore a heightened level of convenience when examining Dynamics 365 and Microsoft Power Platform release plans using the release planner. Enjoy unmatched flexibility as you customize, filter, and sort plans to align with your preferences, effortlessly sharing them. Maintain organization, stay informed, and remain in control while smoothly navigating through various active waves of plans. For more information, visit the release planner.
Highlights from Dynamics 365
Dynamics 365 release wave
Check out the 2024 release wave 1 early access features.
Microsoft Dynamics 365 Sales enhances customer understanding and boosts sales through data, intelligence, and user-friendly experiences. The 2024 release wave 1 focuses on providing sellers timely customer information, expediting deals with actionable insights, improving productivity, and empowering organizations through open configurability and expanded generative AI leadership. Check out this video about the most exciting features releasing this wave.
Microsoft Copilot for Sales continues to deliver and enhance cutting-edge generative AI capabilities for sellers by enriching the Copilot in Microsoft 365 capabilities with sales specific skills, data, and actions. Additionally, the team will focus on assisting sellers on the go within the Outlook and Microsoft Teams mobile apps.
Microsoft Dynamics 365 Customer Service will continue to empower agents to work more efficiently through Copilot, filtering response verification, diagnostic tools for admins and agents, and usability improvements to multi-session apps. Additionally, we’re making enhancements to the voice channel, and improving unified routing assignment accuracy and prioritization. Watch this video about the exciting new features in Customer Service.
Microsoft Dynamics 365 Field Service is a field service management application that allows companies to transform their service operations with processes and experiences to manage, schedule, and perform. In the 2024 release wave 1, we’re introducing the next generation of Copilot capabilities, modern experiences, Microsoft 365 integrations, vendor management, and Microsoft Dynamics 365 Finance and Microsoft Dynamics 365 Operations integration.
Microsoft Dynamics 365 Finance continues on its journey of autonomous finance, building intelligence, automation, and analytics around every business process, to increase user productivity and business agility. This release focuses on enhancing business performance planning and analytics, adding AI powered experiences, easing setup of financial dimension defaulting with AI rules guidance, increasing automation in bank reconciliation, netting, expanding country coverage, tax automation, and scalability. See how the latest enhancements to Dynamics 365 Finance can help your business.
Microsoft Dynamics 365 Supply Chain Management enhances business processes for increased insight and agility. Copilot skills improve user experiences, while demand planning transforms the forecast process, and warehouse processes are optimized for greater efficiency and accuracy. See how the latest enhancements to Dynamics 365 Supply Chain Management can help your business.
Microsoft Dynamics 365 Project Operations is focused on enhancing usability, performance, and scalability in key areas such as project planning, invoicing, time entry, and core transaction processing. The spotlight is on core functionality improvements, including support for discounts and fees, enhanced resource reconciliation, journals, approvals, and contract management, with added mobile capabilities to handle larger projects and invoices at an increased scale. See how the latest enhancements to Dynamics 365 Project Operations can help your business.
Microsoft Dynamics 365 Guides is bringing several new capabilities and enhancements including supporting high-detail 3D model support through Microsoft Azure Remote Rendering and greatly improved web content support that enable customers to build mixed reality workflows that are integrated with their business data. Additionally, support for Guides content on mobile will be generally available in the coming wave through a seamless integration with the Dynamics 365 Field Service mobile application.
Microsoft Dynamics 365 Human Resources will continue to improve recruiting experiences with functionality to integrate with external job portals and talent pools and offer management. We will continue to expand our human capital management ecosystem to include additional payroll partners and build better together experiences that span the gamut of what Microsoft can offer to improve employee experiences in corporations of any size and scale across the globe. See how the latest enhancements to Dynamics 365 Human Resources can help your business.
Microsoft Dynamics 365 Commerce continues to invest in omnichannel retail experiences through advancements in mobile point of sale experiences like Tap to Pay for iOS and offline capabilities for Store Commerce on Android. The business-to-business buying experience is enhanced with new capabilities, and a streamlined order management solution for buyers who work across multiple organizations.
Microsoft Dynamics 365 Business Central is delivering substantial enhancements, with a central emphasis on harnessing the power of Copilot. Available in more than 160 countries, the team is focused on Copilot-driven capabilities to streamline and enhance productivity through enhanced reporting and data analysis capabilities, elevated project and financial management, and simplified workflow automation. We have also upgraded our development and governance tools and introduced improvements in managing data privacy and compliance.
Microsoft Dynamics 365 Customer Insights – Data empowers every organization to unify and enhance customer data, using it for insightful analysis and intelligent actions. With this release, we’re making it easier and faster to ingest and manage your data. AI enables quick insights and democratized access to analytics. Real-time data ingestion, creation, and updates further enable the optimization of experiences in the moments that matter. Check out this video about the most exciting features releasing this wave.
Microsoft Dynamics 365 Customer Insights – Journeys brings the power of AI to revolutionize how marketers work, enabling businesses to optimize interactions with their customers with end-to-end journeys across departments and channels. With this release, we empower marketers with a deeper customer understanding, we enable them to create new experiences within minutes, reach customers in more ways, and continuously optimize results. Thanks to granular lead qualification, we continue to boost the synergy between sales and marketing to achieve superior business outcomes. Check out this video about the most exciting features releasing this wave.
Microsoft Power Platform
Check out the 2024 release wave 1 early access features.
Watch this video about the most exciting features releasing this wave in Microsoft Power Platform.
Microsoft Power Apps focuses on integrating Copilot to accelerate app development with AI and natural language, enhancing user reasoning and data insights in custom apps. The team is also simplifying the creation of modern apps through contemporary controls, responsive layouts, and collaboration features. Additionally, they’re facilitating enterprise-scale development, enabling makers and admins to expand apps across the organization with improved guardrails and quality assurance tools.
Microsoft Power Pages interactive Copilot now supports every step of site building to create intelligent websites—design, page layouts, content editing, data binding, learning, chatbot, accessibility checking, and securing the site. Connect to data anywhere with the out-of-the-box control library and secure the website with more insights at your fingertips.
Microsoft Power Automate is bringing Copilot capabilities across cloud flows, desktop flows and process mining. This will allow customers to use natural language to discover optimization opportunities, build automations, quickly troubleshoot any issues, and provide a delightful experience in managing the automation estate. For enterprise-scale solutions, maintenance is made easier with improved notifications on product capabilities.
Microsoft Copilot Studio brings native capabilities for extending Microsoft Copilot, general availability for generative actions, and geo-expansions to the United Arab Emirates, Germany, Norway, Korea, South America, and South Africa. We’re also introducing rich capabilities to integrate with OpenAI GPT models, along with new channels such as WhatsApp, and software lifecycle capabilities such as topic level import/export and role-based access control.
Microsoft Dataverse continues to make investments focusing on enhancing maker experience by improving app building productivity infused with Copilot experiences, seamless connectivity to external data sources, and AI-powered enterprise copilot for Microsoft 365.
AI Builder invests in three key areas: prompt builder for GPT prompts, intelligent document processing with new features and models, and AI governance improvements, including enhanced capacity management and data policies. These initiatives aim to empower users with advanced generative AI, streamline document processing, and strengthen governance across AI models within Power Apps.
Early access period
Starting February 5, 2024, customers and partners will be able to validate the latest features in a non-production environment. These features include user experience enhancements that will be automatically enabled for users in production environments during April 2024. To take advantage of the early access period, try out the latest updates in a non-production environment and effectively plan for your customer rollout. Check out the 2024 release wave 1 early access features for Dynamics 365 and Microsoft Power Platform or visit the early access FAQ page. For a complete list of new capabilities, please check out the Dynamics 365 2024 release wave 1 plan and the Microsoft Power Platform 2024 release wave 1 plan, and share your feedback in the community forums via Dynamics 365 or Microsoft Power Platform.
The post 2024 release wave 1 plans for Microsoft Dynamics 365 and Power Platform now available appeared first on Microsoft Dynamics 365 Blog.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments