# Connecting a Task Platform to an Enterprise Employee Directory **Disclosure:** This case study is anonymized. The client and employer relationship, production screenshots, source code, tenant information, employee records, internal architecture, and commercial metrics have been excluded. * * * **Industry:** Project and task management **Project type:** Enterprise identity and employee-directory integration **My contribution:** Frontend development, technical research, and API integration **Team:** * [Shebaan Kalim](https://www.linkedin.com/in/shebaankalim/) - UI/UX Designer * [Mohammad Maheer](https://www.linkedin.com/in/mohammad-maheer/) - Backend Lead * [Noman Shahid](https://www.linkedin.com/in/noman-shahid-99a349204/) - Backend Developer * * * ## Overview A task-management platform depends on accurate employee information. Users need to be available for project assignment, task ownership, collaboration, access control, and reporting. For organizations already maintaining employee accounts in a central identity directory, recreating those records manually inside another platform introduces duplicate work and an additional source of inconsistency. The product supported internal project and task management, but organizations using Microsoft’s enterprise identity platform could not directly bring their employee directory into the application. Administrators therefore had to maintain employee information in more than one system. Our team developed an integration that allowed authorized organizations to connect their Microsoft employee directory and synchronize relevant user records with the task-management platform. My contribution covered frontend implementation, technical research, integration behaviour, and coordination with the design and backend teams. * * * ## The problem was duplication, not simply authentication At first, the requirement could sound like a single sign-on feature. The deeper problem was employee-data management. Authentication answers one question: > Is this person allowed to sign in? Directory synchronization addresses a broader set of questions: * Which employees should exist in the task platform? * Which profile fields should be imported? * How should existing users be matched? * What happens when directory information changes? * Which system is authoritative for each field? * How should administrators understand failed or partial synchronization? * What happens when a directory account becomes inactive? The platform needed more than a Microsoft sign-in button. It needed a controlled process for connecting an organization’s directory, retrieving approved employee information, mapping that information into the product, and communicating the result to administrators. | Existing process | Integrated process | | --- | --- | | Add employees manually | Retrieve approved directory users | | Re-enter names and contact details | Map selected directory attributes | | Update records in multiple systems | Refresh directory-managed information | | Discover inconsistencies later | Surface synchronization results | | Repeat onboarding work | Reuse an established employee structure | The integration therefore sat at the intersection of identity, data ownership, security, and user experience. * * * ![The integration replaced repeated employee entry with a controlled process for retrieving and mapping approved directory records.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/5eaca790-6e95-4555-81b3-e8149c98e314.png align="center") * * * ## My contribution I worked across research, frontend development, and integration rather than treating the feature as a conventional settings screen. My contribution included: * Researching the available Microsoft identity and directory-integration approaches. * Understanding the authentication and permission requirements relevant to the frontend flow. * Implementing the connection and synchronization interfaces. * Integrating frontend actions with the application’s backend services. * Presenting employee-directory records for review and synchronization. * Handling loading, successful, empty, partial, and recoverable error states. * Mapping technical integration outcomes into understandable administrator feedback. * Coordinating expected request and response behaviour with the backend engineers. * Working with the product designer to translate security and synchronization requirements into a usable flow. * Keeping the integration consistent with the wider task-management experience. I did not independently build Microsoft’s identity services or the complete backend synchronization system. My responsibility centred on researching the integration, implementing the user-facing workflow, and connecting it reliably to the services developed by the team. * * * ## Researching the integration boundary The work began with understanding how the task platform could authenticate against Microsoft’s identity ecosystem and access permitted directory information. The implementation used the Microsoft Authentication Library to support authentication and token acquisition. Microsoft documents MSAL as the library applications use to obtain tokens for protected APIs, including Microsoft Graph. Microsoft Graph provided the API boundary for accessing authorized cloud-directory resources, including organizational user records. The research was not limited to finding an endpoint. The team needed to consider: * How an organization initiated the connection. * Which permissions were required. * How authentication success or failure was represented. * Which employee attributes the product actually needed. * Where retrieved information was transformed. * How existing platform users were matched. * How synchronization results were stored and displayed. * What administrators could safely retry. * Which operations belonged in the frontend and which required backend control. Identity integrations punish casual assumptions. A working API response is not the same as a complete synchronization design. * * * ## Treating permissions as part of the product experience Enterprise-directory access is security-sensitive. The application should not request broad access without a clear reason, and administrators need to understand what they are authorizing. From a frontend perspective, the connection journey needed to communicate: 1. Why the directory connection was required. 2. What the product would do after authorization. 3. Whether the connection succeeded. 4. Whether employee data could be retrieved. 5. What action was available if authorization failed or was cancelled. 6. Whether further administrator involvement was required. A generic “Something went wrong” message would not have been enough. An authentication cancellation, insufficient permission, expired session, failed backend request, and empty employee directory may all prevent synchronization, but they represent different conditions and require different next steps. > **Engineering principle:** Permission states are not backend details. They determine whether users can understand and safely complete an integration. * * * ![A conceptual view of the authentication, directory-access, mapping, and synchronization boundaries. It does not reproduce the production architecture.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/51a9e72a-06ef-483f-9faf-94659553b357.png align="center") * * * ## Designing synchronization as a lifecycle Synchronization was not a single button followed by a permanent success state. The interface had to represent a process with several possible outcomes: 1. The organization had not connected a directory. 2. An administrator initiated the connection. 3. Authentication or authorization was in progress. 4. The connection was established. 5. Employee records were being retrieved. 6. Records were mapped or compared with existing users. 7. Synchronization completed fully or partially. 8. Some records required attention. 9. A later synchronization refreshed the available information. 10. The connection could expire, fail, or require renewed authorization. Representing these states explicitly helped prevent contradictory interface behaviour. For example: * A connected directory should not continue displaying a primary “Connect” action. * A synchronization in progress should not allow repeated submissions. * A partial result should not be presented as complete success. * An empty directory should not look identical to a network failure. * A failed synchronization should preserve enough context for a safe retry. This was less visually exciting than the final employee list, but it was central to making the feature dependable. * * * ![Directory synchronization required explicit connection, processing, partial-success, recovery, and reconnection states.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/5eaf0ee8-dbcb-4491-ac9d-603c766d80f2.png align="center") * * * ## Mapping directory users into product users A directory user and a task-platform user are related concepts, but they are not necessarily identical data models. The directory may provide many attributes that the task platform does not need. The product may also maintain fields—such as application roles, project membership, or workflow permissions—that should not be overwritten by an external directory update. The integration therefore needed a deliberate mapping boundary. The frontend experience had to support the outcomes of decisions such as: * Which directory fields were displayed. * Which fields were imported. * Which existing users could be matched. * How duplicate or ambiguous records were represented. * Which product-specific information remained locally managed. * What happened when an optional field was unavailable. * How inactive or missing users appeared after a later refresh. This is one reason I would not describe the implementation as “two-way data binding.” Two-way binding is a user-interface pattern. Directory synchronization is a data-governance process involving authority, permissions, matching, lifecycle rules, and failure recovery. Conflating the two makes the implementation sound simpler than it was—and less credible to readers familiar with enterprise identity systems. * * * ## Keeping the administrator informed Synchronization features often fail quietly from the administrator’s perspective. A technical log may explain exactly what happened, but the person using the product still needs an actionable summary. The frontend therefore needed to distinguish among outcomes such as: * Connection established. * Users retrieved successfully. * No eligible users found. * Some users synchronized. * Some records skipped. * Existing users matched. * One or more records required review. * Authorization was no longer valid. * The operation could be retried. The goal was not to expose internal exception details. It was to convert system outcomes into information that helped the administrator decide what to do next. * * * ![A conceptual administration view showing connection status, synchronization outcomes, and records requiring attention.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/cab899ab-98f7-4232-aed1-6864a323a26c.png align="center") * * * ## Outcome The project delivered a user-facing integration for connecting the task-management platform with an organization’s Microsoft employee directory. The completed work supported a more structured approach to: * Establishing the directory connection. * Authenticating the integration. * Retrieving authorized employee records. * Mapping directory information into product users. * Displaying synchronization progress and outcomes. * Handling empty, partial, and unsuccessful results. * Refreshing employee information through later synchronization. From an engineering perspective, the project produced several qualitative outcomes. ### Less repeated employee administration Organizations could reuse existing employee-directory information rather than recreating every profile manually inside the task platform. ### More consistent employee records Mapped directory information provided a clearer basis for maintaining selected identity fields across the two systems. ### A more structured onboarding path Administrators could bring multiple organizational users into the platform through one integration workflow instead of relying entirely on individual entry. ### Better visibility into integration status Connection, synchronization, partial-result, and failure states could be represented explicitly rather than leaving administrators uncertain about what had happened. ### A reusable enterprise-integration pattern The work established frontend patterns for authentication-dependent settings, service connections, asynchronous synchronization, and administrator-facing recovery. These are qualitative implementation outcomes. This case study does not claim a measured reduction in administrative time, error rates, support requests, onboarding duration, or operating cost because supporting analytics and disclosure permission are not available. * * * ## What I learned ### 1\. Identity integration is a trust boundary The interface may look like a settings page, but the underlying feature controls access to sensitive organizational information. ### 2\. Synchronization needs an explicit source of truth Without clear ownership rules, “keeping both systems updated” can create conflicts rather than consistency. ### 3\. Permissions need user-facing explanations A technically correct authorization process can still fail as a product experience when administrators do not understand what is required. ### 4\. Partial success is a first-class outcome When processing multiple employee records, one invalid or conflicting record should not make every other successful result invisible. ### 5\. Directory and product users are different models Mapping should be deliberate. External identity attributes should not casually overwrite application-specific roles or workflow information. ### 6\. Integration research affects frontend architecture Understanding authentication, permissions, data models, and failure conditions early prevented the interface from being designed around unrealistic assumptions. * * * ## Closing reflection This project began as a request to connect a task-management product with Azure Active Directory. The real engineering challenge was broader: connecting two systems with different data models, responsibilities, and security boundaries while giving administrators a workflow they could understand and recover when something went wrong. My contribution was to research that boundary, implement the frontend integration experience, and coordinate its behaviour with the design and backend teams. The strongest result was not merely that employee records could be retrieved. It was that a complex enterprise integration became a manageable product workflow rather than an opaque technical operation. * * * ## Portfolio callout **What I demonstrated** Frontend development · Technical research · Microsoft identity integration · Microsoft Graph · Authentication flows · Data mapping · Synchronization states · API integration · Cross-functional collaboration * * * ## Publication note All diagrams and illustrations accompanying this case study must be labelled **representative** or **conceptual**. They must not be presented as production screenshots, exact architecture diagrams, tenant configurations, measured analytics, or reproductions of the client’s proprietary implementation.