Please see the following frequently asked questions and answers. Please contact us if you have a question and it isn't listed here.
We do offer a published road map.
New functionality is typically being developed based on multiple factors, including:
Please contact us with your desired enhancements and we will assess them on a case by case basis.
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.
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.
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:
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.
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.
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.