How would you test this code?

async function getData() {
  try {
    const result = await fetch('https://contoso.com/api/data');
    if (result.ok) {
      return await result.json();
    }
  }
  catch (e) {
    // handle API errors here
  }
}

More specifically, how would you verify that the code in the catch clause, responsible for handling errors is working properly?

What if your API-handling code is more elaborate? What if you want to use rate limiting headers to back off and avoid getting throttled? And when you get throttled, you want to wait for the designated period and retry the request automatically? How do you verify that your code works correctly?

Using APIs is hard

It's hard to imagine an app that's not connected to an API these days. We use APIs for everything: from authentication, to data storage, to integrating AI. APIs are literally everywhere. And yet, it's surprising to see how hard it still is to build robust apps that use APIs.

The APIs we use in our apps are built by different vendors. Each API works differently than the other. But that's fine. Using their docs, we can integrate these APIs in our apps just fine. We can even go as far as to automate testing different scenarios relevant to our app. But not all of them.

While it's easy to get APIs to work, it's hard to break them. Yes, you can easily send an invalid request and see it respond with an error, but that's hardly something you'd see in production, unless you missed something fundamental. What is really hard about working with APIs is simulating different error states, like rate limits, throttling or servers getting overloaded.

What makes it even harder, is that vendors who publish APIs, often spend more time in their docs communicating how their APIs work rather than how their APIs behave when they fail. "It's a matter of perception" - you could say. But if you've worked with APIs a bit, you know that API failure is not a matter of "if" but "when". And having proper docs that describe erroneous behavior makes all the difference.

How developers handle API errors

Handling API errors is hard. Here's how developers typically deal with it.

Wrap the whole request in a try..catch

Probably the most frequently used solution out there is to wrap the whole web request in a try..catch clause. If calling an API fails for whatever reason, the app catches the error and shows a generic error. I bet you've seen an error similar to An error has occurred. Reload the page more than once. This is exactly, because developers used a generic try..catch statement.

Using this approach gives you an easy way out. After all, as a developer, you don't have to care about the exact API error. Something went wrong in an API you don't own, so you can't do nothing about it, right? So you show a generic error to the user, asking them to retry. What else can you do, right?

Use a dependency

There are dependencies that you can use in your project to help you handle API errors. Their functionality can be as simple as handling basic OData errors to handling throttling with exponential back offs. Thanks to these dependencies you can be smarter and automatically recover when possible without bother the user.

While it sounds great, what makes you so sure that the dependency will work properly with the APIs that you use in your app? Have you actually checked it? How would you though?

Make the API fail

When developers want to see how their app behaves when it gets throttled, they sometimes overload the API on purpose. They'll keep calling it until they exceed the quota or force a server error due to too high resource consumption.

It's far from perfect for both the API vendor and the developers. API vendor loses precious resources sometimes even leading to service outage, and developers incur additional costs. But how else would you verify how the app actually behaves when it gets one of these elusive errors?

Simulate API errors with mocks

More experienced developers, especially when they build a product, might go as far as mock APIs they use. Rather than calling the actual API, they simulate API responses in code what allows them to test different edge cases. This isn't trivial to do.

First, you need to have a thorough understanding of the API that you're using and its different behaviors. Can you get throttled? Does the API communicate rating limits? What other error states could the API communicate that you should consider? When do these errors occur and what is the shape of the error response that your app gets?

Once you know all of this, then you need to setup the necessary infrastructure to mock API calls and simulate the different errors. Simulating simple errors isn't hard. But it gets complicated when you get to simulating more complex behaviors like rate limiting that spans a series of requests.

And after you figured it all out, you also need to keep this in sync with the actual behaviors of the APIs that you use in your app.

Using APIs properly is hard

There's more to using APIs than meets the eye. A 200 OK response is just the tip of the iceberg. If you want to build robust apps that use APIs, you need to properly handle possible errors, and you have to verify that you're doing it correctly. This has nothing to do with your app's functionality, but what's the alternative? Hoping for the best while knowing that it's just a matter of time until your app breaks and loses someone's work?

See for yourself how your app will behave when APIs fail

The good news is, that there's a better way for you to see how your app will behave when the APIs that it uses fail. It allows you to see not just regular API failures, but rate limiting, throttling and any other type of error that an API might return. And you can do it without changing a single line of code in your app or standing up specific testing infrastructure and elaborate tests. Here's how.

Microsoft Graph Developer Proxy - an open-source proxy from Microsoft, allows you to simulate API errors. When you start it on your developer machine, it intercepts web requests from your app and returns simulated errors. You can use the Developer Proxy for simulating simple errors and more complex behaviors like throttling on any API. And because it's a proxy, you can use it with any type of app, build on any technology stack.

Check out this single-page app connected to Microsoft Graph that shows you information about people. At first, it seems to work just fine:

Let's see what happens, when one of the API calls would fail:

Because the developer didn't implement any error handling, as soon as an API call failed, the whole app failed leaving the user with an empty screen. And remember what we discussed: it's just a matter of time before calling an API fails, so you better be prepared for it.

See how quickly we were able to find a flaw in this app? Notice, that we didn't have to change anything about the app or stand up any testing infrastructure. All we did was start the Developer Proxy and run the app. That's it.

Using the Developer Proxy, you'll find all kinds of issues related to using APIs in your apps:

• How does your app behave when calling an API fails? Can it handle the error gracefully or will it crash losing the user's work?
• Is the error message that you show to the user relevant to the type of error that occurred?
• Do you even need to show an error message to the user or can you automatically recover, for example by retrying the failed request after some time?
• When loading data takes longer than expected, is it clear to the user that your app is still working?
• Could you cache data to use as fallback in case calling the API fails?

These are just some examples of insights about your app that you'll get when you test it with Microsoft Graph Developer Proxy.

Building robust apps that use APIs doesn't have to be hard. Microsoft Graph Developer Proxy allows you to see for yourself how your app will behave when calling APIs that it uses fails. With Microsoft Graph Developer Proxy, you can test any kind of app, using any API. Break your app on your box, handle errors gracefully and deploy your app to production with confidence. Your customers will thank you.

Get started at https://aka.ms/graph/proxy.

On a tenant of one, your app never fails. Calling Microsoft Graph and other APIs on Microsoft 365 just works. But when it gets used at scale in production, only then you get to see if you built it correctly.

When you build a great application, and it gets widely adopted, it's used a lot. Depending on the size of your organization, your app might be used by hundreds or thousands of simultaneous users, issuing even more requests to Microsoft Graph and other APIs. Microsoft Graph can handle a lot, but even it has its limits, and when you reach them, by calling Graph APIs too often, instead of a response with data, you'll get errors like 429 Too Many Requests. You're throttled.

Throttling is temporary. It's a mechanism to help servers resume regular service operation. By instructing clients to back off for a bit, servers hosting cloud APIs get a chance to get back to normal operation. That's the good news. The bad news is, that, unless you use an SDK that does it for you, you need to handle throttling yourself.

The problem with throttling is that it's elusive. It occurs only in certain conditions. This makes it really hard to test how your app will react when throttled: will it back off and wait as instructed, or will it break with an exception?

This is exactly why we built the Microsoft Graph Developer Proxy: a tool to help you test how your apps respond to API errors. Seeing is believing for a reason. With the Graph Developer Proxy, you no longer need to hope for the best. You can verify, even on your tenant of one, how your app will react when suddenly Graph APIs will return errors.

🙋‍♂️ Download the Graph Developer Proxy, test your apps, and I'm looking forward to hearing what you learned.

PS. You can use Microsoft Graph Developer Proxy with any type of app: client-side apps running in the browser or back-end services running on a server.

In my last newsletter, I shared with you a few resources to help you get started building apps for Microsoft 365. If you work with an organization that uses Microsoft 365 for work, you've got a great opportunity to use your developer skills and bring data and insights stored on Microsoft 365 into your work apps.

Recently I've been working on another app that shows how you'd find meeting times and schedule a meeting for you and other people in your organization. This is a common scenario for work apps, and while it's available in Outlook, having it directly in the work app helps your colleagues stay in the flow of work.

📝 Check out the article I published about this scenario on freeCodeCamp.

📺 Here's also a recording from a recent community call where I showed the app in action.

👾 And if you're interested in digging into it some more, here's the code.

Remember, the best way to check the app out, is to see it running. Follow the setup steps in the readme and run it on your tenant.

I've got some more ideas for new demos that I'll be working on in the coming weeks, so stay tuned for more updates. Meanwhile, if you've got any questions, don't hesitate to reach out by leaving a comment.

Many work apps need the ability to schedule a meeting with others in their organization. Here's how to do it for apps connected to Microsoft 365.

Work apps need work data

Work apps serve a specific purpose: they help you track projects, follow orders or manage resources. But rarely do they contain all the information that users need to complete their work. Typically, information about people, their calendars, or communication is stored elsewhere, like in Microsoft 365. And that's a shame because completing a task requires users to switch between different apps, which is detrimental to their productivity. Unless of course, you bring work data into your work app.

Find a meeting time and schedule a meeting on Microsoft 365

A common scenario for work apps is to schedule a meeting with others in the organization. While it sounds trivial, the app must be able to access attendees' calendars, find a suitable meeting time and schedule the meeting. And that's where Microsoft Graph comes in.

Recently I published an article on freeCodeCamp that shows you how to build an app connected to Microsoft 365 that can find a meeting time and schedule a meeting.

The app shows you how to make the best use of features available in the Microsoft Graph Toolkit and Microsoft Graph to build a UI that you could integrate with another app.

Check it out, and I'm looking forward to hearing what you think!

Recently, I showed you how you can build in under 10 minutes a simple personal assistant that shows users meetings they have left for the day. Here's an even easier way to do it using the Microsoft Graph Toolkit.

Show upcoming meetings for a Microsoft 365 user

Showing upcoming meetings is a common scenario when integrating Microsoft 365 in work applications. Using Microsoft Graph, your app can connect to Microsoft 365 and access a user's calendar. By building a specific query, you can retrieve meetings between now and the end of the day.

Recently, I walked you step by step how to complete this scenario in under 10 minutes using the Microsoft Graph JavaScript SDK. But there's an even easier way to do it using the Microsoft Graph Toolkit.

The easiest way to connect to Microsoft 365

Microsoft Graph Toolkit (MGT) is a set of components and authentication providers connected to Microsoft 365. MGT takes away the complexity of implementing authentication, loading data from Microsoft Graph, and showing it in your app. And if anything goes wrong, it also properly handles exceptions. Microsoft Graph Toolkit's components are highly customizable so that you adjust them to your app.

A quick comparison: signing in to your app

To understand the benefits of using Microsoft Graph Toolkit, let's have a look at an example: let users sign in to your app using their Microsoft 365 account.

Typically, you'd need code similar to the following:

<html>
<head>
  <title>Upcoming meetings</title>
  <script src="https://alcdn.msauth.net/browser/2.28.3/js/msal-browser.min.js"></script>
</head>
<body>
  <h1>Upcoming meetings</h1>
  <div id="auth"></div>
  <script>
    (() => {
      const scopes = ['Calendars.Read'];
      const msalConfig = {
        auth: {
          clientId: '021aa7bb-9aaa-4185-92ad-c7b75a7fb9d2'
        }
      };
      const msalClient = new msal.PublicClientApplication(msalConfig);

      function render() {
        msalClient
          .handleRedirectPromise()
          .then(response => {
            const accounts = msalClient.getAllAccounts();

            if (accounts.length === 0) {
              document.querySelector('#auth').innerHTML = '<button>Login</button>';
              document.querySelector('#auth button').addEventListener('click', login);
            }
            else {
              document.querySelector('#auth').innerHTML = '<button>Logout</button>';
              document.querySelector('#auth button').addEventListener('click', logout);
            }
          });
      }

      function login(e) {
        e.preventDefault();
        msalClient.loginRedirect({
          scopes
        });
      }

      function logout(e) {
        e.preventDefault();
        msalClient.logoutRedirect();
      }

      render();
    })();
  </script>
</body>
</html>

In comparison, here's the same functionality built using Microsoft Graph Toolkit:

<html>
<head>
  <title>Upcoming meetings</title>
  <script src="https://unpkg.com/@microsoft/mgt@2/dist/bundle/mgt-loader.js"></script>
</head>
<body>
  <h1>Upcoming meetings</h1>
  <mgt-msal2-provider client-id="021aa7bb-9aaa-4185-92ad-c7b75a7fb9d2" scopes="Calendars.Read"></mgt-msal2-provider>
  <mgt-login></mgt-login>
</body>
</html>

See the difference? And we didn't even get to the good part yet: calling Microsoft Graph!

With Microsoft Graph Toolkit you can focus on building your app and solving problems for your customers. Microsoft Graph Toolkit takes care of the rest.

Show upcoming meetings with Microsoft Graph Toolkit

To give you a more complete comparison, I rebuilt the same scenario using Microsoft Graph Toolkit.

The best way to check out the app is to run the app locally by following the instructions in the README.

Because retrieving the data using MGT is so simple, I added some extra UI to differentiate between the different states of the app.

The MGT Agenda component, which I use to show the upcoming meetings offers different templates to customize the UI. When loading the data, I show a simple text message:

<mgt-agenda>
  <template data-type="loading">
    <div class="loading">Loading...</div>
  </template>
  <!-- trimmed for brevity -->
</mgt-agenda>

When there's no data to show, I take into account the fact that there might be no data because the user hasn't signed in to the app yet, or that the user might have no upcoming meetings:

<mgt-agenda>
  <template data-type="loading">
    <div class="loading">Loading...</div>
  </template>
  <template data-type="no-data">
    <div class="no-data" data-if="mgt.Providers.globalProvider.state === mgt.ProviderState.SignedIn">
      <!-- No upcoming meetings -->
    </div>
    <div class="no-data" data-else>
      <p>Sign in to view your upcoming meetings</p>
    </div>
  </template>
</mgt-agenda>

I use for this the conditional rendering capability in MGT.

To show upcoming meetings, for simplicity, I use the default template provided with the Agenda component.

Summary

Microsoft Graph Toolkit is a great way to build apps that connect to Microsoft 365. It takes away the complexity of connecting to Microsoft 365 and provides a set of components that you can use to build your app and bring in the data and insights from Microsoft 365. Because MGT components are highly customizable, you can seamlessly integrate them in your app.

Run the sample app locally and see for yourself how easy it is to build apps that connect to Microsoft 365 using Microsoft Graph Toolkit.

Learning something new is often daunting, especially when it's something like developing for a new platform. Building for a platform comes with all kinds of specific knowledge like what tooling, SDKs, and APIs to use, how to integrate your app, and how to package and distribute it. The great thing is though, that platforms are multipliers that allow you to tap into an existing audience. Yes, you need to learn a lot to truly benefit from a platform, but the great thing is that you can start small and build your way up.

🥇 Get started

To help you get started, I recently published a tutorial that shows you how to build your first app for Microsoft 365 in under 10 minutes. Literally. This tutorial is a great place to start, either for yourself or the new developers you're onboarding in your organization.

Check it out: How to build your first app for Microsoft 365 in 10 minutes .

📆 First scenario: show upcoming meetings

After you've built your first app, you're ready to work on a simple scenario: show upcoming meetings for the signed-in Microsoft 365 user. It's not overly complex, but it teaches you a common scenario that you might need when integrating work apps with Microsoft 365.

Check out the tutorial: How to show upcoming meetings for a Microsoft 365 user.

🚀 Supercharge your app with Microsoft Graph Toolkit

Both tutorials use the Microsoft Graph JavaScript SDK which gives you the most robust way to connect to the Microsoft Graph API. If you're looking for an even quicker way to integrate with Microsoft Graph, you should check out the Microsoft Graph Toolkit: a collection of web components and auth providers to connect your apps to Microsoft 365.

See how I built the upcoming meetings apps using the Microsoft Graph Toolkit.

💯 Extra!

As a subscriber to my newsletter, I'll give you a sneak peek at something I've been working on in the last few days: a single-page app connected to Microsoft 365 that allows you to find a meeting slot for a few attendees who are on Microsoft 365.

Check it out here: Find meeting times and schedule a meeting using Microsoft Graph Toolkit.

It's similar to the functionality that you get in Outlook but which you could integrate into your work apps.

The best way to learn is to run these apps and see them in action!

If you're building apps for Microsoft 365, I'd love to hear about them. Leave a comment and I'm looking forward to hearing from you.

Learn how you can build a simple personal assistant in under 10 minutes that'll show a Microsoft 365 user the meetings they have left for the day.

Show upcoming meetings for a Microsoft 365 user

Recently, I published an article on freeCodeCamp that shows you how you can build in just 10 minutes a simple personal assistant that shows upcoming meetings for the signed-in user.

Showing upcoming meetings is a common scenario when integrating Microsoft 365 in work applications. It shows you how to get information from the user's calendar and check their availability for a particular time slot. And it's also a great way to get started with building apps on Microsoft 365.

The tutorial shows you the basics of setting up auth in a single-page app and using the Microsoft Graph JavaScript SDK to connect to the Microsoft Graph API. It also demonstrates working with calendar views and formatting dates.

Give it a try, and I'm looking forward to hearing what you think.

When building apps connected to Microsoft 365, before you can bring in data from Microsoft 365, you need to set up authentication. Here's a reference sample of a Single Page App that shows how to do that.

Work apps need work data

Microsoft 365 is a popular set of applications that organizations across the world use to facilitate collaboration and communications. It's also a platform that you can use to build apps for work and streamline how people work together.

These apps can show up inside Microsoft 365, bringing information from line of business systems into the apps that people use every day. They can also be standalone web-, desktop-, and mobile apps that combine data and insights from Microsoft 365 with data from other systems.

No matter which type of app you choose to build, you need to start with connecting to Microsoft 365, which means you need to set up authentication.

Reference sample: Single Page App connected to Microsoft 365

Because you can build many types of apps connected to Microsoft 365, there are many ways to set up authentication. And if you're just starting building apps for Microsoft 365, it might not be quite clear for you what it is exactly you need and how to combine the different parts together.

To help you get started, I built a sample Single Page Application that shows you how to:

• setup authentication with Microsoft 365 in a Single Page Application
• let users sign in and -out with their Microsoft 365 accounts to your app
• retrieve data from Microsoft 365 using Microsoft Graph
• register your app with the Microsoft identity platform

The sample app is built using plain JavaScript, which lets you reuse the code in any JavaScript framework. In the repo, you'll find the app built in two ways, using immediately invoked function expressions (IIFE) and using ES modules (ESM). It's largely a matter of preference which one you choose to use, but I wanted to show you both approaches.

If you want to see how I built the app step by step, check out my recent article on freeCodeCamp.

Learning something new is often daunting, especially when it's something like developing for a new platform. But that doesn't have to be the case. Let me show you, how you can build your first Microsoft 365 app in just 10 minutes.

Building for a platform

Building for a platform isn't trivial. It comes with all kinds of specific knowledge you have to have like what tooling, SDKs, and APIs to use, how to integrate your app, and finally how to package and distribute it. And I haven't even mentioned auth.

It's a lot to learn, and it's easy to get overwhelmed. The trick is though, that you don't have to learn everything about everything at once. Often, you can start simple and build up from there.

Build your first Microsoft 365 app in 10 minutes

Recently, I published an article on freeCodeCamp that shows you how you can build your first Microsoft 365 app in just 10 minutes.

Sure, the app is simple and doesn't do much, but when building it, you'll learn the fundamental concepts of building apps on Microsoft 365. And after these 10 minutes, you'll have a functional app that works and retrieves data from Microsoft 365, and which you can use as a starting point for more complex apps.

Give it a try, and I'm looking forward to hearing what you think.

Last week at the Viva Connections & SharePoint Framework Community Call I had the pleasure of presenting how to use the SharePoint Framework to customize list forms. Here's a quick overview of the topics we covered.

Form customizers - a new type of SPFx extension

In SharePoint Framework (SPFx) v1.15, which was released in July '22, Microsoft introduced form customizers - a new type of extension that allows you to extend list forms. Using form customizers, you can build a custom experience for New, Edit, and View forms of a list.

Anatomy of an SPFx form customizer

Form customizers are in essence SPFx extensions: they have the onInit method, to initialize data, and the render method to build the UI. Additionally, form customizers have two methods that you need to call, to notify the SPFx page runtime of how the user interacts with the form: this.formSaved(), when the data has been changed and saved, and this.formClosed() when the user closed the form without modifying the data.

export default class HelloWorldFormCustomizer
  extends BaseFormCustomizer<IHelloWorldFormCustomizerProperties> {

  public onInit(): Promise<void> {
    // Add your custom initialization to this method. The framework will wait
    // for the returned promise to resolve before rendering the form.
    Log.info(LOG_SOURCE, 'Activated HelloWorldFormCustomizer with properties:');
    Log.info(LOG_SOURCE, JSON.stringify(this.properties, undefined, 2));
    return Promise.resolve();
  }

  public render(): void {
    // Use this method to perform your custom rendering.
    this.domElement.innerHTML = `<div class="${ styles.helloWorld }"></div>`;
  }

  public onDispose(): void {
    // This method should be used to free any resources that were allocated during rendering.
    super.onDispose();
  }

  private _onSave = (): void => {
    // You MUST call this.formSaved() after you save the form.
    this.formSaved();
  }

  private _onClose = (): void => {
    // You MUST call this.formClosed() after you close the form.
    this.formClosed();
  }
}

To allow you to optimize the performance of your solution, form customizers don't load the data for the underlying list item. Instead, you need to load the item yourself and choose which information you want to load in the onInit method. When building an Edit form, you also need to load information about the ETag, to ensure that you're not overwriting data that has been changed by another user.

export default class BasicsFormCustomizer extends BaseFormCustomizer<IBasicsFormCustomizerProperties> {
  // item to show in the form; use with edit and view form
  private _item: {
    Title?: string;
  };
  // item's etag to ensure the integrity of the update; used with the edit form
  private _etag?: string;

  public onInit(): Promise<void> {
    if (this.displayMode === FormDisplayMode.New) {
      // we're creating a new item so nothing to load
      return Promise.resolve();
    }

    // load item to display on the form
    return this.context.spHttpClient
      .get(this.context.pageContext.web.absoluteUrl + `/_api/web/lists/getbytitle('${this.context.list.title}')/items(${this.context.itemId})`, SPHttpClient.configurations.v1, {
        headers: {
          accept: 'application/json;odata.metadata=none'
        }
      })
      .then(res => {
        if (res.ok) {
          // store etag in case we'll need to update the item
          this._etag = res.headers.get('ETag');
          return res.json();
        }
        else {
          return Promise.reject(res.statusText);
        }
      })
      .then(item => {
        this._item = item;
        return Promise.resolve();
      });
  }

  // trimmed for brevity
}

Previewing a Form Customizer

When you scaffold a Form Customizer, the SharePoint Framework Yeoman generator adds 3 configurations to your serve.json file, that allow you to quickly preview your Form Customizer with the New, Edit, and View form.

To preview your Form Customizer, run in the command line:

gulp serve --config helloWorld_NewForm

where helloWorld is the alias of your Form Customizer and NewForm is the form display mode that you want to preview. For the list of available serve configurations, check the config/serve.json file in your project.

Separate- vs. one form customizer

When building form customizers, you can choose to build a separate Form Customizer for each form display mode, or you can build one Form Customizer that supports all display modes. You can also choose to override only a specific display mode and use the default behaviors for other display modes. This gives you flexibility about how you organize your code and what kind of experience you want to build for your users.

Deploy your Form Customizer

After you built your Form Customizer, you need to deploy it by associating it with a content type. You can associate it with an instance of a content type in a specific list or a site content type. If you want the Form Customizer to be used with all instances of the content type in your tenant, associate it with the content type in the content type hub site from which it will be synced to other sites in your tenant.

To register a Form Customizer with a content type, set the ID of the Form Customizer component (the value of the id property from the Form Customizer's manifest) in the ContentType.DisplayFormClientSideComponentId property of the content type. If your Form Customizer is configurable, you can pass its configuration as a JSON string in the ContentType.DisplayFormClientSideComponentProperties property. This set of properties is also available for the New- (NewFormClientSideComponentId, NewFormClientSideComponentProperties) and Edit (EditFormClientSideComponentId, EditFormClientSideComponentProperties) form.

You can set these properties declaratively using the Feature framework in the SPFx solution, but the preferable way is to do it programmatically using the REST or CSOM APIs, through remote provisioning solutions.

What can you build with form customizers?

Form customizers are a great way to extend the user experience on top of lists. By combining them with list formatting, you can build applications that are hosted on SharePoint and don't require any additional resources.

Because you own the full canvas of the list form, you've got a lot of flexibility when it comes to rendering the form. And since form customizers are powered by SPFx, you've got access to Microsoft Graph and line of business APIs to bring in additional data.

Here's the full recording of the community call starting with the form customizers section.

Once again, thanks to everyone for joining us, and don't hesitate to reach out if you have any questions.

What are you going to build with form customizers?

When you use apps for work, they rarely show you all the data that you need to get the full context of your work. And that's a shame because that information is often readily available to you, and could be integrated into your app.

It's all about the context

Say you're asked to build an app to manage projects for your organization. You build a web app, and host it in the cloud. Using the app you can store information about projects, customers, and project teams. Your organization uses another app for communication, and another for storing files, so rather than duplicate the functionality you point to existing apps for easy access.

Your app works, but is it convenient to use? Way too often you see your colleagues switch back and forth between your app, and other apps to get the full context of their work: information about the project, recent emails to the customer, project team communication, project files, and people who work on the project. What could you have done differently?

Bring work data into your app

Say, your organization uses Microsoft 365. The project information is stored in your app. To communicate with the project team, they need to go to Teams. To get the project files, they need to go to SharePoint. Communication with the customer is in email in Outlook, and information about people is accessible via Teams, Outlook, or SharePoint, depending on where they are at the moment. Instead of switching between all these different apps, why not bring the relevant data to your app?

Work apps need work data. Even though your app has a specific purpose, like managing projects, people using it will need more information to get the full context of their work. Projects are commissioned by a customer and run by a project team. While you work on projects, you create files, and communicate about them. The same goes for managing orders, or any other business scenario. So why should that work context be fragmented? Why not offer your colleagues all the information they need right where they need it: in your app?

If you use Microsoft 365, information about people, and files is readily available to you, and accessible using Microsoft Graph - the API for Microsoft 365. Instead of requiring your users to jump between the different apps, you can use Graph to bring contextually relevant information to your app. You can bring in emails sent to, and received from the customer. You can bring in project files that the project team has recently worked on. You can show information about the project team members, their location, and time zones right in your app. You can have all this information, and more available in the context of your app so that your colleagues spend more time working, and less time switching contexts.

The great thing about using Microsoft Graph is that it allows you to tap into data, and insights that are stored in Microsoft 365. You get to benefit from all functionality from Microsoft 365, such as storage, access management, or disaster recovery, and at the same time, can integrate it in a contextually relevant way with your app.

Bringing work data to your app doesn't need to come at the cost of a lot of extra work. If you're on Microsoft 365, use Microsoft Graph, and tap into organizational data, and insights stored in Microsoft 365 that are relevant to your app. Check out what's possible using Microsoft Graph.