Please see the following frequently asked questions and answers. Please contact us if you have a question and it isn't listed here.

Do you have a road map of upcoming features we can see?

We do offer a published road map.

New functionality is typically being developed based on multiple factors, including:

  • the amount of client demand for a feature
  • the applicability and generic utility of a feature for current and future clients
  • our own assessment of being able to implement functionality in a way that will be user friendly, have good performance, be secure, and be maintainable
  • the value proposition of functionality compared to the built-in functionality included in Dynamics 365 portals

Please contact us with your desired enhancements and we will assess them on a case by case basis.

We require guidance on the implementation. What support do you offer?

We offer documentation that shows how to perform the configuration efforts, and we will respond to specific support oriented questions during your implementation. If a more direct consultation is needed to participate in detailed design and implementation efforts, a support agreement can be purchased from KPMG Adoxio to obtain a dedicated number of hours for such a consultation.

How is the content from Connected 365 added to the web page it is displayed in?

The user interfaces that are displayed in the portal are dynamically injected as inline HTML into the web page they're hosted on. It is not displayed in an IFRAME.

On a more technical level, this is done by initially downloading and executing a JavaScript file from the Connect 365 web application, which then performs subsequent cross-domain web requests to retrieve extra resources from the Connect 365 web application for rendering and injecting the HTML content into the web page. The rendered content will reside in the DOM of the hosting web page, and it will be affected by CSS on the hosting web page.

Does Connect 365 perform any local data storage? How does it manage data locally and what type of connections are made to external services?

Connect 365 retrieves and saves data directly to and from the data sources where information is coming from and being saved to. For example, with Dynamics 365 and SharePoint, it connects directly to their web servers using their web APIs, and serves the retrieved content directly to the portal user's web browser.

Connect 365 doesn't persist data locally on the server it is hosted on, however it does perform temporary in-memory caching of data for performance reasons - it would be very slow if it didn't, and this is a standard and necessary practice in building high-performance applications that don't get throttled by external systems, including Dynamics 365 and SharePoint.

Connect 365 never initiates requests on its own. As a web application, Connect 365 executes on a request-response based system. Requests initiated by Connect 365 are always first driven by an end user performing an action. As an example with SharePoint:

  1. An HTTP request is sent from an end-user's web browser to Connect 365 to display or save information to/from SharePoint
  2. Connect 365 sends HTTP requests to Dynamics 365 and SharePoint to retrieve/save the information
  3. Connect 365 returns an HTTP response for display to the end user's web browser

We have data residency requirements where data cannot leave our country. Can Connect 365 support this scenario?

We use Azure for hosting the Connect 365 application and will deploy it to the region closest to the Dynamics 365 server and portal. Wherever there is an Azure data center we can host Connect 365 in that region. Please see the Azure regions documentation from Microsoft for exact physical locations.

Where the data that is served by Connect 365 is ultimately going to be delivered and stored once accessed in the portal via Connect 365 cannot be restricted since it is a web application that is accessible over the internet and the users could be physically located anywhere in the world. If you have ideas or solutions for restricting user access by region, please contact us for further discussion.

Data residency and where data is stored at rest is controlled by the combination of where Connect 365 is hosted (see previous paragraphs) and the services that Connect 365 is integrating with to provide access to within a portal. For example with Dynamics 365 and SharePoint that are Office 365 services, Microsoft manages the hosting of the data and their documentation or support would need to be consulted to understand where these services store their data. Please see the Where your data is located documentation from Microsoft for further information, or contact a Microsoft representative for further questions about their data hosting.

How does Connect 365 authentication work?

Connect 365 is a web application. It connects to Dynamics 365, SharePoint, and other services using their respective web services and authentication mechanisms. It uses Azure AD B2C for portal end-user authentication.

 Why is Azure AD B2C required for authentication? We already use and want to keep using local authentication.

Azure AD B2C is required for any functionality that is used in an authenticated experience. Most installations are used where portal contacts are performing actions while signed in and the contact's identity needs to be ascertained and their permissions to perform an action to be validated.

Connect 365 and Dynamics 365 Portals are separate web applications. When using local sign-in on the portal, it isn't possible for an externally hosted web application such as Connect 365 to determine and validate the identity of the signed-in contact. Azure AD B2C provides a federated authentication system (single sign-on) that allows Connect 365 to ascertain the signed in contact.

When a portal has existing contacts that have previously used local authentication, they will need to be switched over to instead sign-in with Azure AD B2C. See the Migrate identity providers to Azure AD B2C documentation by Microsoft for instructions on how to configure the portal to support migrating contacts from local authentication to Azure AD B2C authentication.

It is also worth noting that Microsoft recommends using Azure AD B2C with Dynamics 365 portals and deprecating all other forms of authentication. See the Migrate identity providers to Azure AD B2C documentation by Microsoft for details - in particular they state:

The portal supports a configurable security system that lets our customers support multiple authentication systems. The portal includes its own local credentials in addition to federating with external identity providers using standard protocols such as OIDC, SAML, and WS-Federation. Going forward, we recommended that you use only Azure AD B2C identity provider for authentication and that you deprecate other identity providers.