Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Hello GP Community,
A big topic that we are getting a lot of discussion around is regarding the Workflow Actions that you can include in your Workflow email notifications. We are seeing a lot of customers setting this up to get the Approve and Reject actions in their notification, but there's a general lack of knowledge in how to get this working so that you can click the Approve button and approve the document when you're anywhere in the world, not just when you're connected to your local network. The intent of this blog post is to give an overview of the various pieces involved with this process, so that you're able to approve documents from outside the network.
The main thing dictating whether you’ll be able to approve from outside your network is the hostname that you enter into Workflow Setup for your GP Web Services. If this hostname is publicly resolvable, and the port is open, the approval will work. If you’re just entering the NETBIOS name of the Web Services server, then the approval will only work while connected to the internal network. This post is going to cover the components needed to set up a publicly resolvable hostname for use with Web Services.
The first concept to cover is DNS, which stands for Domain Name Servers. DNS is how internet addresses are mapped to IP addresses. DNS servers are the backbone of any enterprise network, and they're the backbone of public internet as a whole. When you type www.bing.com into the address bar of your Web Browser, that request goes to a public DNS server (usually provided by your ISP) which responds with the proper IP address of the server hosting the Bing website. Once your browser knows the IP, it can connect and display the site.
The same concept applies to internal networks, the only difference being that Active Directory has its own DNS server that is used to assign IP addresses to computers on the network. When you try to open a file through a network drive, the DNS server of your local network is what provides the proper IP address of the file you're accessing. If a local DNS server cannot resolve the request, then it will forward on the request to another DNS server until it reaches a server that can provide the IP, otherwise a 404 error is returned.
The next concept to cover is the Web Services service that is required for approving via email. During the install of Web Services, you are not prompted for nor allowed to change the hostname on which the service is bound. The config files are written using the NETBIOS name of the server on which it is installed. NETBIOS name resolution requires that you be connected to the same domain and share the same DNS server as the Web Services server. In a ‘flat’ network, this is very simple.
In the Workflow setup, you are prompted for a URL at which Web Services can be reached. In a flat environment, you’d just enter the NETBIOS name of the server. However, for the links to be resolvable from outside the domain (where NETBIOS name resolution doesn’t work) you’ll have to have something different set up. You have to own a domain, and you have to set up a PTR record on the domain you own to forward that PTR traffic to the static IP of your network’s firewall. You then have to open and forward port 48620 traffic to the Web Services server. The external request now looks like this.
For NETBIOS name resolution to work, there simply needs to be an A Record in DNS on the domain to map the local IP to the NETBIOS name. This record is created when you join a machine to the domain, so this happens automatically. Any machine joined to the domain can be reached at their NETBIOS name or their FQDN, which is NETBIOS.DOMAIN.COM. Point being, you cannot use a NETBIOS name if you want the request to be approved from outside their domain. Public DNS servers do not have NETBIOS name records for a local machine on your private network, this is where the requirement comes for having to own a public domain name, one purchased via a public registrar. Once you own the public domain name space, then you can either just use the entire domain label for Web Services, but most would want to use a PTR record, so the traffic could flow via label.domain.com instead of taking the entire domain. You may want your website on domain.com, and web services on web.domain.com.
Once you have a publicly resolvable hostname, this is what you will enter into Workflow Setup and then the emails will be generated with this public hostname.
The final concept to cover is to bind the service itself with SSL, since the traffic would be routing via public internet. We definitely recommend doing this, the steps to do so can be found at the following post:
You'll just need to get a certificate for the public hostname that you set up, follow the blog post to bind this certificate to your service, and then enter this hostname into Workflow Setup and check the "Use SSL" option.
Dynamics GP Systems Support
Business Applications communities