Microsoft

There are an array of cloud applications under the Microsoft umbrella, and Skuid can access several of its Office365 cloud applications—seen in Skuid’s table of contents—with its pre-configured data source types.

Most Office365 OAuth configurations are set through Azure Active Directory, so you must first set up an app registration within Azure Active Directory and obtain the API credentials you’ll be using for your authentication providers. Follow the instructions below to do this, and then open the topic page for your chosen Microsoft data source to learn more.

Note

You may also use these credentials for any Office365 REST API, should you need to use a service that does not yet have a pre-configured data source type in Skuid.

Azure Active Directory: App registration and OAuth Credentials

Azure Active Directory (Azure AD) handles the connection between Microsoft’s cloud-based products and outside applications, in this case Skuid. To facilitate the OAuth authentication process, you’ll need to work with your IT admin to configure an app within Azure AD, set the permissions for that app, and then use its OAuth credentials to set up a Skuid authentication provider.

Note

You will need access to Azure with your Office365 account to start this process. If you do not have access, contact your IT administrator to arrange this setup.

Warning

Because implementations vary and making adjustments can potentially impact others in the enterprise, Skuid encourages you to work closely with your IT administrator and follow Microsoft’s documentation for Azure AD while configuring the app registration.

You’ll need to configure the following items within your app registration:

  1. Set your sign-on URL/reply URL to the callback URL for your Skuid site.

    When using Skuid on Salesforce, the callback URL will depend on several things:

    • Whether or not the Remove Instance Names from URLs critical update is activated
      • If the above critical update is not activated, then the Salesforce org’s instance
    • If set, the Salesforce org’s My Domain
    • Whether the org is a developer edition or sandbox org

    Each of these variables will change parts of the callback URL.

    There are also different URLs needed based on whether the Skuid page is deployed using the Redirect or skuid:page Visualforce component override method. Because of this, it’s best to enter two callback URLs for Skuid on Salesforce orgs.

    To ensure the accuracy of your callback URLs, fill out the form below to generate the appropriate Salesforce callback URLs for your org:

    Note

    Unsure what your instance and My Domain are? The URL of the Skuid Pages list within the Salesforce Classic layout is a quick way to find the information needed for callback URLs. For example:

    https://customMyDomain-dev-ed--skuid.na30.visual.force.com/apex/PageList

    From the above URL you can deduce the following:

    • customMyDomain is the My Domain
    • -dev-ed indicates this is likely a developer’s edition org
    • na30 is the instance.

    How these URLs are formed [[]]

    If the Remove Instance Names critical update is activated, and the org’s My Domain is configured, the callback URLs should be:

    • https://<myDomain>--skuid.visualforce.com/apex/skuid__oauthcallback
    • https://<myDomain>--c.visualforce.com/apex/oauthcallback

    If the org’s My Domain is configured, their format should be:

    • https://<myDomain>--skuid.<Instance>.visual.force.com/apex/skuid__oauthcallback
    • https://<myDomain>--c.<Instance>. visual.force.com/apex/oauthcallback

    If the org’s My Domain is not configured, then the URLs will be:

    • https://skuid.<Instance>.visual.force.com/apex/skuid__oauthcallback
    • https://c.<Instance>.visual.force.com/apex/oauthcallback

    If the org is a developer’s edition or sandbox, the skuid/c section of the URL will be prepended with -dev-ed– or –sandboxName– respectively.

  2. Within your app registration’s manifest, set “oauth2AllowImplicitFlow”: true.

  3. Set the appropriate required API permissions for the application you wish to access:

    • Dynamics - Within the Dynamics CRM Online API:

      • Access CRM Online as organization users
      • Depending on your Azure instance, you may instead need this API permission: Commonly Used Microsoft APIs > Dynamics CRM > user_impersonation
    • Outlook - Within the Office 365 Exchange Online (Microsoft.Exchange) API:

      • Read and write user and shared calendars

      • Read and write user and shared mail

      • Read and write user and shared contacts

      • Create, read, update and delete all tasks a user has access to

      • Send mail as a user

      • Read and write user and shared calendars

      • Read and write user and shared mail

        Note

        There are two identically named permissions for both Read and write user and shared mail and Read and write user and shared calendars.

        On hover, they will display their proper scope names: Mail.ReadWrite.Shared and Mail.ReadWrite.All, as well as Calendar.ReadWrite.Shared and Calendar.ReadWrite.All. All four of these permissions are required for proper functionality.

    • OneDrive - Within the Office 365 SharePoint Online (Microsoft.SharePoint) API:

      • Read and write user files
  4. Generate the proper OAuth credentials for your Skuid authentication provider:

    • The application ID is equivalent to Skuid’s client ID
    • The key is equivalent to Skuid’s client secret

With the above settings configured in Azure AD, you’re ready to begin configuring the OneDrive and Outlook data sources within Skuid.