Microsoft Access Reporting Architect-Fabric Connect Workbench

Microsoft Access Reporting Architect Fabric-Connected Reporting Workbench Project Overview We are seeking a senior Microsoft Access application and reporting architect to design a stable, durable reporting environment connected to Microsoft Fabric. Microsoft Fabric will remain our governed data platform and source of truth. Access will serve as a controlled reporting and analytical workbench over curated Fabric data. This is not primarily a Power BI development role, an Access-to-Power-BI migration project, or a basic Access query-writing assignment. The central requirement is to create an Access environment that allows the business owner to perform direct, iterative, and ad hoc analysis without putting validated recurring reports or production processes at risk. Business Need Many of our most valuable reporting questions are exploratory and may be needed only once. For example, we may begin by comparing the sales performance of 20 stores that received a particular display rack against all other stores. After reviewing the first result, we may decide to divide the comparison group into stores that received other merchandising support and stores that did not. The final analytical structure may not be known until the initial results are reviewed. The business owner understands the data and can create or revise Access queries directly. We therefore need an environment that supports active self-service analysis while protecting stable production reporting. A small percentage of ad hoc analyses may later become recurring reports. Those should be reviewed, tested, documented, and promoted into a protected production environment. Proposed Architecture We expect the Access environment to include two clearly separated functions: 1. Analytical Workbench A safe environment where the business owner can: Create and modify queries. Build temporary comparison groups. Perform ad hoc and one-time analysis. Create crosstabs and detailed outputs. Export results to Excel. Revise the analysis as business questions evolve. Work without disrupting validated recurring reporting. 2. Protected Production Reporting Application A controlled environment containing: Validated recurring reports. Reusable base queries. Standardized report parameters. Controlled Excel export routines. Documented dependencies. Tested release versions. Protected production objects. Appropriate backup and recovery procedures. Fabric should remain the governed source of data, shared mappings, history, and reusable business rules. Access should not become an undocumented second warehouse or an independent source of truth. Initial Scope The selected specialist will be expected to: Review the current Access reporting environment and representative reports. Recommend an appropriate Access architecture connected to Fabric. Define the separation between analytical, development, and production work. Establish a safe workspace where the business owner can create queries directly. Create reusable base queries or data-access components. Recommend where filtering and aggregation should occur in Fabric versus Access. Improve performance when working with remote or large datasets. Establish naming, documentation, backup, versioning, and release standards. Develop a controlled process for promoting an ad hoc analysis into recurring production reporting. Support detailed Excel exports and polished Excel reporting templates. Train the business owner to work safely within the analytical environment. Prototype Requirement The initial engagement will include a small prototype using one representative reporting problem. The prototype should demonstrate: Connection to curated Fabric data. A protected production structure. A separate analytical workspace. The use of temporary store or product comparison groups. Efficient query execution. A repeatable detailed report. A controlled Excel export. Documentation showing how the solution is organized and maintained. We will use the prototype to evaluate the architecture before expanding the environment. Required Experience Candidates should have substantial hands-on experience with: Designing Microsoft Access front-end applications. Architecting durable Access reporting environments. Splitting or separating development and production Access applications. Linked tables, QueryDefs, pass-through queries, and remote SQL data sources. ODBC connectivity and connection management. Performance optimization against large remote datasets. VBA development, error handling, and automation. Excel export automation and template population. Access forms, reports, macros, and reusable query structures. Version control, backups, release management, and deployment. Dependency documentation and maintainable naming standards. Supporting business users who perform some direct query development. Important Distinction Experience merely using Access is not sufficient. We are specifically seeking someone who has designed and maintained Access architecture that: Protects stable production reporting. Allows controlled experimentation. Supports active business users. Connects efficiently to a governed external data platform. Can be maintained without depending entirely on one developer. Candidates whose primary approach is to move all reporting into Power BI are unlikely to be a fit for this role. Power BI may be used selectively for polished client-facing dashboards, but detailed reporting, ad hoc analysis, crosstabs, and Excel outputs may remain in Access. Helpful Additional Experience Experience with any of the following is helpful but secondary to deep Access expertise: Microsoft Fabric. SQL Server or cloud SQL platforms. Power BI semantic models and dashboards. Data warehouse reporting views. Sales, depletion, inventory, account, or territory reporting. Client-facing Excel reporting packages. Engagement Structure The project will begin with: Review of the existing environment. Written architecture recommendation. Development of a small working prototype. Evaluation of the prototype. Expansion into the broader reporting environment if the approach is successful. The specialist should be comfortable working collaboratively with: The business owner, who will define and test reporting needs. The Fabric data engineer, who manages the governed data platform. Other reporting or technical resources as needed. Proposal Instructions Please include: Examples of Access applications or reporting environments you personally architected. A description of how you separated experimental or development work from production reporting. Your experience connecting Access to remote SQL-based data platforms. An example of improving Access performance against a large remote dataset. Your approach to versioning, deployment, backups, and release control. Your experience automating Excel outputs from Access. How you would allow a business owner to create queries safely without putting production reporting at risk. Your hourly rate and near-term availability. Please do not provide only a general list of Microsoft technologies. We are most interested in the specific Access architecture work you have personally designed and implemented. Screening Questions Describe an Access application or reporting environment that you personally architected. What made the architecture stable and maintainable? How would you separate an owner’s experimental queries from validated recurring production reports? How would you connect Access to a large governed remote data source without importing the entire dataset locally? What Access objects or processes would you protect, and how would you prevent an experimental change from disrupting production? How do you handle versioning, backups, deployment, and release management for Access front-end applications? Describe a project where Access populated a formatted Excel reporting template or automated a recurring Excel export. What work should occur in the remote database or Fabric layer, and what work is appropriately handled inside Access? How would you structure the environment so the business owner can build simple queries directly while relying on you for architecture, performance, and production stabilization?