Access needs to be granted, equipment prepared, documentation completed, and teams aligned long before day one. As a result, onboarding success depends less on how employee data is stored and more on the ability of an organization to collaborate across teams.

This is where SharePoint and Power Automate can play a critical role.

At DMC, we have evolved our own onboarding approach over time, moving from SharePoint Designer workflows to a more modern solution built on Power Automate, SharePoint lists, and Modern Pages. This approach has allowed our organization, as well as clients we’ve assisted, to create a more flexible and maintainable onboarding system aligned with current Microsoft 365 best practices.

If you are considering a SharePoint and Power Automate solution because you’ve outgrown the capabilities of your HRIS or you want to add some rigor to current manual processes, there are some important considerations to make before making the switch.

1. Consider Where HRIS Platforms Add Value and Where They Fall Short

HRISs play an essential role in onboarding. They are designed to manage employee records, benefits, and compliance-related processes, and they do this very well.

However, HRIS platforms are not typically built to orchestrate dynamic, cross-department workflows.

Common limitations include:

• Rigid, one-size-fits-all workflows.
• Limited configurability without vendor involvement.
• Lack of visibility for non-HR teams.
• Weak integration with the tools employees use every day, such as Teams and SharePoint.

As a result, teams often fall back on email, spreadsheets, or ad hoc tracking methods to fill the gaps.

HRIS systems are designed to manage employee data, not to coordinate operational tasks. And when those tasks apply to different teams across departments, HRIS systems can really fall short. This is not a shortcoming of HRIS platforms; it’s simply a matter of scope.

That said, the most effective approach is not to fully replace an HRIS but to extend it. This is where SharePoint and Power Automate can act as a flexible coordination layer, connecting people, tasks, and systems across the onboarding lifecycle.

2. Assess Your Current Onboarding Process and Requirements

Before designing a solution, it is important to understand how onboarding actually works in your organization today.

As we’ve mentioned, onboarding is not a single workflow. It is a collection of tasks owned by different teams, each with its own processes, timing, and requirements.

So, it’s important to ask some of the following questions before designing a new onboarding system:

• Who is responsible for each task? Responsibility often varies depending on the task and the employee. For example, setting up IT credentials may be handled centrally by a single team member, while preparing a desk or workspace may depend on local office staff.
• What tasks are required for different types of hires? Full-time employees, contractors, and remote workers may all follow different onboarding paths.
• How do onboarding tasks vary by office location? On-site onboarding tasks often differ from office to office. For example, one location may need to coordinate building access and employee badging, while another may need to prepare a parking space or other workspace accommodations.
• What documents, approvals, or systems are involved? Consider offer letters, compliance forms, equipment requests, and system access.
• How is progress tracked today? Many teams rely on email threads, spreadsheets, or disconnected tools, which can make it difficult to maintain visibility.

An effective onboarding system must reflect this complexity and variation. It needs to support cross-functional ownership while providing a single, clear view of progress.

3. Evaluate the Tradeoffs of Hard-Coded Onboarding Workflows

When HRIS platforms fall short in coordinating tasks, organizations often turn to custom workflows.

In many cases, these workflows are hard-coded to define:

• Which tasks are created.
• Who each task is assigned to.
• When tasks are triggered.
• How dependencies and due dates are structured.
• Which onboarding stage initiates the work.

This approach can work initially, especially for straightforward onboarding processes. However, onboarding rarely stays static.

As organizations grow and evolve, certain changes are inevitable. HR might introduce new compliance steps; a team may suddenly need to reassign responsibilities; new office locations may require different onboarding activities; a start date or timeline changes, etc.

When these rules are embedded into a workflow, even small changes call for developers to update, test, and redeploy every solution. Over time, this approach slows system improvement, increases maintenance, and introduces risk. Over time, this slows down improvement, increases maintenance overhead, and introduces risk.

The more rigid the system, the harder it becomes to adapt.

4. Consider a Configurable, Template-Driven Approach with SharePoint and Power Automate

A more flexible approach is to separate workflow logic from task definition.

Instead of hard-coding tasks into Power Automate flows, onboarding tasks can be stored as configurable templates in SharePoint lists. Each template defines the task, its owner, timing, and any relevant dependencies.

Power Automate can then dynamically read these templates and generate tasks based on the specific onboarding scenario.

This approach offers several advantages:

• Business users can manage the process without modifying workflows.
• Changes do not require redeployment, reducing dependency on developers.
• Onboarding can scale more easily across roles, locations, and employee types.
• Variations can be handled dynamically, rather than through separate workflows.

This model also complements HRIS platforms well. HRIS systems remain the source of truth for employee data, while SharePoint and Power Automate handle task coordination and execution.

5. Plan for Visibility, Ownership, and Adaptation

The most effective onboarding systems make work visible and ownership clear.

Key design considerations include:

• Role-based views for HR, IT, managers, and employees.
• Clear task ownership, so nothing falls between teams.
• Real-time status tracking, reducing the need for follow-ups.
• Scalability, to support new roles, locations, and hiring volume.
• Reusability, allowing the same framework to support offboarding and other workflows.

When teams can see what needs to be done, who is responsible, and what is complete, onboarding becomes more predictable and less dependent on manual coordination.

A Flexible, Modern Approach to Onboarding

HRIS platforms are essential for managing employee data and meeting compliance standards, but can fall short when it comes to onboarding task management. SharePoint and Power Automate can help coordinate teams through essential onboarding tasks, from the moment a new hire signs their offer letter to long after their first day.

Whether you’re looking to extend an existing onboarding process or build something new, DMC can help! We’ve assisted organizations in moving from spreadsheets and email-driven processes to scalable, automated onboarding systems built on Microsoft 365. By combining these tools and adopting a configurable, template-driven approach using SharePoint and Power Automate, organizations can build onboarding workflows that adapt over time and grow with the team.

The post Extending Your HRIS with SharePoint and Power Automate for Employee Onboarding appeared first on DMC, Inc..

Integrating SharePoint into Ignition can reduce friction between organizational teams without compromising system reliability. The core draw is bringing enterprise information closer to operations and reducing manual work like exporting reports, emailing files, hunting for the latest SOP, or duplicating data across systems.

In some organizations, SharePoint may already be the system of record. As part of the Microsoft suite of tools, it is depended on for document management and collaboration. In this case, integrating SharePoint into Ignition can expand system capabilities to leverage the strengths of each tool and reduce separation or duplication between operation/production and other teams.

Other organizations may be looking to move away from paper-driven or manual processes. In these cases, the combination of Ignition and SharePoint can allow the concerns of both manual production or record keeping and old-fashioned document storage and sharing to be addressed in a way that sets teams up for lower overhead.

What Ignition and SharePoint Each Do Best

As a SCADA platform, Ignition excels at real-time and near-real-time operations. It connects to control system components, surfacing information to users in a way that is conducive to effective and efficient decision-making during operation. Additionally, it’s built around SQL database connectivity rather than proprietary data storage formats. It natively integrates with databases such as PostgreSQL, Microsoft SQL Server, and MySQL, enabling robust historical data logging, reporting, and analytics. This makes it well-suited for data-driven applications and integration with other data analytics tools. Ignition also supports Python scripting throughout the platform, allowing engineers and developers to build custom logic, automation routines, and integrations. Its API-driven design and flexible UI development tools enable deep customization, making it adaptable.

SharePoint, on the other hand, is designed for document handling and collaboration. At its core, SharePoint provides a centralized and structured environment for storing, organizing, and managing digital content across an organization. Unlike traditional file servers, it layers document management capabilities such as version control, metadata, and permissions directly onto cloud-based storage, making information both more accessible and more governable. Its built-in search engine further strengthens this by allowing users to retrieve relevant documents and data across sites, libraries, and even connected Microsoft 365 services. Procedures, manuals, reports, and audit artifacts all fit naturally into SharePoint’s structure and methodology. Beyond document storage, SharePoint serves as a flexible platform for building internal portals and collaborative workspaces, with sites acting as hubs for departments or projects and Power Automate integration providing options for automating workflows like approvals, document routing, and notifications.

The value in integration between these two systems comes from exposing information between them, while allowing each to preside over the scope of work it was designed for. When humans are in the loop doing document management, approvals, or reviewing reports, integrating SharePoint into Ignition provides benefits in terms of transparency between teams and the reduction of duplicated data.

Common Integration Use Cases

Publishing Reports

One common pattern for integration is publishing content out of Ignition. Scheduled reports, batch summaries, or downtime logs can be automatically uploaded to a SharePoint document library where supervisors and engineers already expect to find them.

From a technical standpoint, this typically involves formatting data into a document and then using Ignition’s scripting capabilities and SharePoint’s APIs (such as Microsoft Graph or SharePoint REST endpoints) to programmatically upload the files to the appropriate SharePoint site, folder, or document library. Metadata — such as production line, batch ID, timestamp, shift, or product type — can be attached to each file on upload, making the content easier to search, filter, and organize.

This allows other organizational teams or team members – such as engineers or managers – to access the latest production summaries, downtime logs, or performance reports directly from SharePoint, alongside other operational and business documents. This creates a more unified information flow between OT (operational technology) and IT systems, which reduces separation or duplication between plant-floor data and enterprise documentation.

Additionally, storing Ignition-generated content in SharePoint enables downstream workflows. For example, the arrival of a new batch summary could automatically trigger a review or approval process via Power Automate, notify stakeholders in Microsoft Teams, or be archived according to corporate retention policies. Over time, this turns SharePoint into not just a storage location, but an active collaboration and governance layer for industrial data.

Document Display in Ignition

Another high-value use case for integrating SharePoint with Ignition is using SharePoint as the authoritative source of documentation and then surfacing that information directly within Ignition’s operator interface. In many facilities, critical operational information — such as standard operating procedures (SOPs), wiring diagrams, and manuals — requires formal version control, approvals, and periodic reviews, making SharePoint a natural system of record. However, operators and technicians typically spend most of their time inside Ignition HMIs rather than browsing SharePoint sites. If they must leave the HMI to search for documents, it can cause frustration and increase the likelihood that outdated or unofficial copies will be used.

Through integration, Ignition screens can dynamically link to or embed documents that reside in SharePoint. Technically, this can be accomplished by storing document URLs or metadata in Ignition and using web views or API calls to retrieve the correct file from SharePoint in real time. The system can also be designed to filter documents, so users see only the most relevant information. For example, when an operator selects a specific piece of equipment in Ignition, the screen could automatically display the latest approved maintenance checklist associated with that asset.

Because the documents remain managed in SharePoint, this approach preserves strong governance without sacrificing usability. SharePoint’s built-in versioning ensures that only the most current, approved documents are presented, while historical versions remain available for auditing or reference. Approval workflows, document review cycles, and change tracking can all continue to operate in SharePoint, independent of Ignition. From the operator’s perspective, however, they simply see the right document in the right place at the right time, embedded seamlessly within their normal workflow.

This integration also improves consistency and reduces risk. Instead of multiple copies of procedures floating around on local drives or printed binders, there is a single, controlled source of truth in SharePoint that is directly connected to the HMI. If a procedure is updated due to a safety change or process improvement, the new version becomes instantly available to all operators through Ignition without requiring manual redistribution.

Exception Log Tracking

Some teams leverage SharePoint lists as a lightweight mechanism to capture operational information that is important from a business, quality, or compliance perspective but not critical to real-time control. Instead of pushing everything into an industrial database or embedding every data-capture requirement directly into Ignition, teams use SharePoint as a parallel system for structured tracking of contextual or administrative records that surround plant activity.

In practice, this often includes exception logs, operator notes, minor deviations, near-miss reports, shift comments, maintenance observations, or non-critical audit records. These are pieces of information that benefit from being organized, searchable, and reviewable across departments, but do not require the speed, determinism, or reliability guarantees of a control system database. SharePoint lists are well-suited for this because they allow teams to define custom fields, validation rules, and views without requiring a dedicated application.

Integration with Ignition in this scenario usually takes the form of one-way or loosely coupled data exchange. For example, Ignition might provide an operator interface that allows users to submit an exception entry or add contextual notes about a process event. Behind the scenes, Ignition scripts or API calls then create or update corresponding entries in a SharePoint list via Microsoft Graph or SharePoint’s REST endpoints. Alternatively, Ignition could automatically log certain classes of events — such as repeated minor alarms or operator overrides — into SharePoint for later review by supervisors or quality teams.

The critical design principle in this pattern is that SharePoint remains outside of the control loop. Ignition continues to handle all real-time monitoring, interlocking, alarming, and automation logic, while SharePoint serves as a complementary system with improved visibility for team collaboration. Operations teams retain a responsive, high-performance control environment in Ignition, while IT and quality teams gain structured, shareable records in SharePoint that can be integrated with broader business processes. Over time, this creates a balanced ecosystem where industrial data and human-centered documentation coexist without overloading the control system with non-operational responsibilities.

Integration Approaches and Architecture

Most SharePoint integrations with Ignition are built around API access using either the SharePoint REST API or Microsoft Graph API, which are invoked directly from Ignition scripting. SharePoint’s APIs expose a robust integration surface that allows external systems to programmatically interact with SharePoint as a structured content and data platform. Through standard web-based endpoints, external applications can create, read, update, and delete sites, document libraries, files, and list items, and manage metadata, permissions, and versioning. All interactions are secured through Entra ID authentication and role-based access controls, ensuring that integrations follow the same security policies as human users.

Within Ignition, this connectivity is implemented through its Python-based scripting environment, which can issue HTTP requests to these APIs. Using built-in networking functions or third-party libraries, Ignition scripts can transmit data and handle responses in real time. This enables Ignition to reliably read from and write to SharePoint while staying tightly aligned with Ignition events, tags, and transaction logic.

Generally, a middleware layer that handles authentication and API complexity is also required. This can take the form of a simple web service, server-less compute function, or gateway-hosted service and helps to manage authentication tokens and segregate concerns. As an example, this might take the form of a Python application that runs on the ignition gateway, with the following flow:

Integration Considerations

Governance and Ownership

As is common when tools are bridging the gaps between organizational teams, it is worthwhile to consider who is responsible for maintaining each part of the solution long-term. In the case of this integration, it is likely that the controls or operations team will own the Ignition side of the system, including screens, control logic, and scripts, while IT will own the SharePoint side, including permissions/authentication and structure. Defining the boundary and interface between these two sides to the integration explicitly can reduce friction and maintenance overhead down the line. Things to consider:

• Folder structures and naming conventions
• Retention and archiving rules
• The change management process

Authentication and Security

Ignition authenticates to SharePoint as an application (rather than receiving delegated permissions from a user log-in) using a dedicated service account. This requires setting up an app registration in Azure Entra ID, with the following basic steps:

1. Create a New App Registration in Entra ID via the Azure Portal
   • At this point, Entra ID creates the application identity with an Application (client) ID and Directory (tenant) ID. These values are important for later configuration.
2. Add a Certificate
   • You must prove the app’s identity when requesting tokens. Go to “Certificates & secrets” and upload a certificate; the thumbprint and private key for this certificate will later be used to authenticate.
3. Assign API Permissions (Scopes)
   • This defines what the app is allowed to do. Common examples include: Sites.ReadWrite.All (to create/update files and lists) or User.Read.All  (to read user profiles).
4. Grant Admin Consent
   • Most SharePoint/Graph permissions require tenant-wide approval. Without this, your app will not be able to access SharePoint in most enterprise tenants.
5. Use These Values in Your Integration
   • You will typically need the following to acquire access tokens from Entra ID:
     • Tenant ID
     • Client (Application) IDCertificate (thumbprint + private key)
     • Certificate (thumbprint + private key)
     • API Scopes (e.g., Graph’s User.Read or SharePoint’s Sites.ReadWrite.All)

In addition to setting up an app registration for Ignition, general security guidance, such as not hardcoding credentials and using the lowest permissions required are important for implementing the integration as securely as possible.

Expectations and Error Handling

Ensuring the usefulness of the integration depends on keeping expectations aligned with what each tool is good at and implementing robust error handling to account for connectivity issues. For instance, it is reasonable to expect SharePoint to handle files and metadata in a batched or event-driven way. SharePoint excels at handling files and list-formatted data, and API based access aligns well with low-frequency updates. However, it would not be reasonable to use SharePoint to store high-frequency operational data or to act as a data historian; it is not set up to handle streams of data, and it is not optimized for time-series information. Similarly, it is likely reasonable to expect that the normal operational state of the system would be Ignition and SharePoint communicating with relatively low response times, but likely not reasonable to assume perfect connectivity or 100% uptime.

To this end, it is valuable to implement handling to account for cases that would differ from the reasonable expectations for the system. This could include:

• Including timeouts to prevent calls from blocking indefinitely,
• Clear logging for failures,
• Retry logic; likely with limits on the total number of retries,
• Caching of queried data (like SOP’s or manuals) when practical

Considering these cases allows the overall system to continue functioning as smoothly as possible when something goes wrong, and forethought into failure handling allows for a simpler debugging process.

Building Your SharePoint and Ignition Integration

Integrating Ignition with SharePoint in a secure, scalable, and maintainable way is technically feasible for many organizations, but doing it well often requires a blend of OT, IT, and cloud expertise that rarely exists fully within a single team. For this reason, working with an experienced consulting partner like DMC can be highly valuable when undertaking this type of integration.

A knowledgeable partner brings deep, practical experience with both Ignition and the Microsoft ecosystem. This helps avoid common pitfalls around integration interfaces and authentication. Rather than learning through trial and error, organizations benefit from proven design patterns and best practices that have been refined across multiple projects and industries. DMC maintains Ignition Premier Integrator status and Microsoft Solutions Partner status and has extensive experience developing solutions in both Ignition and SharePoint. Additionally, DMC’s diverse experience across both manufacturing/OT and business-centric/IT projects enables us to facilitate conversations between organizational teams and stakeholders, ensuring the solution is designed in a way that works for all users. This cross-functional perspective is often just as important as the code itself.

Finally, working with a partner accelerates delivery. Instead of dedicating internal resources to building and troubleshooting unfamiliar components, teams can focus on their core responsibilities while the consultant handles the complexity of the integration. The result is a more robust solution delivered faster, with a clearer path for future enhancements.

The post Integrating SharePoint into Ignition: A Practical Guide appeared first on DMC, Inc..

Requirements

Power Automate

We will use Power Automate, Microsoft’s cloud-based business automation platform, to automate this process. In Power Automate, a single executable task is called a flow. Each component of a flow is called an action.

To copy and populate Word documents in Power Automate, we must use an action from the Word Online connector which requires a Power Automate Premium account.

SharePoint Online

For the flow we will write, we need a cloud-based location to source the Word document template and a destination to send the populated template copy. If your organization uses SharePoint Online, there are actions we can add that retrieve and save files in SharePoint out of the box!

Word

The document templates are created in Word and saved as a .docx file.

Implementation

Part 1: Creating Your Word Template

Let us start off with an example document template that has some placeholder fields.

To denote the {insert} placeholder values as fields that we want to be able to overwrite with our flow, mark each of them as a “Plain Text Control” which you can do on the “Developer” tab in the Word editor.

We can then configure the control by selecting it on the page (it should show up as a gray box outline around the placeholder text) and select the “Control Properties” widget next to the plain text control button.

This will open the following dialog. You can name the control anything, but make sure it is descriptive if you are adding multiple controls to your template so there is no confusion when connecting data sources to the controls in Power Automate.

At this point, the file is ready for use as a template. Let us save it to a location in SharePoint Online so that our Power Automate flow can make copies of it. If the account creating the flow is different from the account which uploads the document, make sure that it is saved to a location that the former can also access.

Part 2: Creating the Flow in Power Automate

To create the template population flow, go to the Power Automate console in your browser and click “Create.” The type of flow you create depends on what will trigger it. There are three cloud-native flow types available:

1. Automated Cloud flow – a flow that is triggered through a designated event.
2. Instant Cloud flow – a flow that is triggered manually through the Power Automate console or through an external command like an HTTP request.
3. Scheduled flow – a flow that is triggered automatically on a set schedule.

Your situation may differ, but as an example, we will create a flow that is manually triggered via an HTTP request that contains all the data populated to the template.

Once we’ve created the flow, we need to source the content that will populate our template. Since our content passes into the flow with the HTTP request trigger, we will update the output schema of the trigger so we have references to the values we want to pull from the request body. Again, this will differ based on the type of trigger/data source for your flow. Here is an example of what this looks like with our example HTTP trigger, where we define the input schema and specify that the request includes the “projectName” value.

Next, we will add the “Populate a Microsoft Word Template” action. When we select the template file, we can see the control fields that can be populated in our flow in the “Advanced Parameters” section, identified by the names we specified in the template document. We will specify the values that should be inserted to each field.

The output of the Word connector is an unsaved copy of our populated template file, which we will then pipe to the “Create File” action that saves the file in a specified location in SharePoint.

Once you specify the location to save the file, the flow is complete. Go ahead and save the flow and test it out.

Further Considerations

As stated before, access to template documents is not guaranteed when you create the flow, based on the SharePoint sites your account has access to. It may be worth setting up flows with an admin account in your organization to ensure they will not break if permissions for certain users are modified. Additionally, updating the template file may cause issues, as references to the control fields in your flow may break when the source template document is updated in the future. If your flow is mission-critical, make sure there is a well-defined system for modifying your template files to avoid any unexpected failures.

Power Automate is incredibly useful for automating workflows like these Word templates we have populated. Additionally, you can easily extend a flow like this with conditional logic or other downstream actions for SharePoint/other integrated services, all in one portal. DMC has extensive experience with Power Automate and many other digital workplace technologies. To see how your business processes can be optimized, give us a call!

The post Copying and Populating Word Documents in SharePoint Online Using Power Automate appeared first on DMC, Inc..

Step 1: Define Your Tenant-wide Content Type 

It’s best to do this step through the portal. In the admin-portal, navigate to manage content types, and add a content type. When you publish, go ahead and add the desired content type. You can upload this content type as a file, or it can be a relative site URL to a file that lives in a different site collection.

Note: Using the relative site URL to your content type template may or may not work. This is a documented issue with Microsoft and has required us to contact Microsoft support to fix this. Yet, using a relative site URL is the ideal method as it allows you to keep the document template updated whenever a change is made to the template online. Otherwise, any changes you made to the document template you have uploaded will have to be saved and re-uploaded.

Step 2: Publish the Defined Content Type

In the same admin portal, you can publish the defined content type, which adds the content type to all the site collection across your tenant. You need to repeat this step when you make an update to the content type template. Since you are publishing the content type template, any changes you make to the template will only take effect if you re-publish those changes again. 

Step 3: Sync the Content Type

Through the UI, you can add these content types to whichever library you choose. Go to the library you wish to modify, select Library Settings, and add an existing content type from the site. I recommend doing this manually if you only need to use the document template through one or two site collections. Adding a content type from the existing site through the UI syncs the content type automatically on the backend.

In our case, we had to figure out how to sync these content types programmatically and add them to several libraries. To do so, we used the Microsoft.Graph package allowing us to sync content types down to a site collection. We had to sync the desired content types for each site collection. Then, could we programmatically access them across the site collection’s libraries. 

Here is an example of how to use the Microsoft.Graph package to sync down content types:

Step 4: Add Content Type to Desired List/Content Types

Once you have synced down the content types to the site collection, you are able to use it however you please across the different libraries in the site collection. Here is a code example of adding a content type to a site collection:

Putting this all together, we are now able to successfully sync down any custom content types to any site collection and add the desired content types into whichever library requires the content type.

A common use case for this method is iterating through a number of site collections. Using these functions may help you with each site collection. Below is a use case of how I would sync down the desired content sites programmatically for a site collection.

While there are a few steps involved, programmatically syncing your content types across all site collections can help your organization standardize templates in SharePoint Online. 

The post SharePoint Online: Programmatically Syncing Templates Across All Site Collections appeared first on DMC, Inc..

Pros: The Share Button is Convenient 

If you’ve used SharePoint Online or OneDrive, you’ll recognize the share button located in the navigation ribbon above your document library. This button appears as a default unless you turn it off on a tenant level. 

When you click the share button, it prompts you to type the name, group, or email of the party you would like to send the document to. It also offers a field to send a message along with the file. An automated email containing the file and any message you included will arrive in the recipient’s inbox. Users appreciate how easy it is for any employee to share content with other people inside or outside of their organization using the share button.   

Cons: The Share Button Can Cause Permissions Issues 

While Microsoft’s share button is convenient for users, it can cause some unanticipated issues on the backend. When people use the share button, it creates a unique set of permissions for that one file or location. Then, permissions are managed at the level of the individual name of the user who received it rather than at a companywide level. 

This can become an issue when a change happens. Instead of managing permissions in Active Directory by team, you may have to edit permissions for every user who received the file via share button. This can cause headaches for IT and cost extra time for maintenance.  

For example, if someone shares the OneNote file for Project Awesome with Jane, Jamal, and Jennifer using the share button then permissions are created at each of their individual name levels. If this option is continuously used, the organization could have a permissions web on their hands. Instead, users should share the file with the Project Awesome Team and that team should be defined as containing Jane, Jamal, and Jennifer. In this instance, future changes can be addressed at the Project Awesome Team level rather than every individual member. When you’re making sitewide changes this time savings can add up.  

 
Sharing documents at a team level (right) is preferred over sharing documents at an individual level (left.

Best Practices for Sharing Files 

The best practice for sharing files within your organization is to consider a companywide strategy. In general, permissions should be handled at the organizational level and not be managed by individuals.  

There is a configuration setting at the site collection level that allows you to only share with people who already have permissions. This will allow users to send an email sharing the document and it does not alter the permissions. As part of your organizational strategy, consider choosing this option by default and being cautious about where to leave the share button feature on. 

The share button can be useful if you need the ability to share documents with users outside of your organization. However, it should be used judiciously. DMC can help you set this up. 

Use the Copy Link Option to Share Files 

Fortunately, Microsoft offers more than one way to share files. Rather than use the share button, users can copy a link to the file and share it with others.  

Select your file and click the three dots or overflow menu to the right of the file name. A navigation window will appear.

After you click “copy link,” you can paste the link into an email or chat window. This method has the added benefit of being able to customize your message to the recipient when including the document link, rather than generating an automated email.  

If you need to further customize the permissions, click “Settings” on the “Link copied” window. This will display additional options for sharing the document link if they are available per your organization’s link-sharing strategy.  

While Microsoft makes it easy to share documents between users, the method that users choose may have unintended consequences for permissions at the user level. Considering a companywide strategy for document management permissions and communicating best practices to your users can save your IT team time and keep your organization productive.  

The post Pros and Cons of Using the Share Button in SharePoint appeared first on DMC, Inc..

Onboarding employees seamlessly and with no stress is crucial to employee success. As DMC has grown throughout the years, we’ve automated this process, so tasks don’t get forgotten and there is less time spent tracking down the status of these tasks.

In the past, we have automated the process of creating onboarding tasks and assigning those onboarding tasks using a SharePoint Designer workflow, in conjunction with SharePoint of course. As SharePoint Designer is being phased out, we have switched to using Power Automate, modern SharePoint lists, and page views to make this solution more robust and keep up with the current Microsoft technology practices.

The Onboarding Process

Onboarding is a process that happens over time both before an employee starts and continuing well into their first few weeks or months. In SharePoint, we create a custom list to track the status of each new employee depending on what stage they are in. We add new employees to the list as soon as they accept an offer, and then the workflow is immediately started. The different stages are defined based on how many days until or after the employees start date. Our workflow allows for these stages to be dynamic and allow for changes over time.

Once the stages are defined, the super users of this solution can define the different tasks that need to be assigned to different people throughout the onboarding process. These tasks have expiration dates relative to the start dates of the new employees.

These tasks are configurable and customizable to your company. There are many small details that go into the onboarding process, and these details are always changing. We create a SharePoint list that acts as the "template" for all onboarding tasks. This ensures that your team can update the process when needed. The workflow uses this template to automatically copy and assign the specific tasks needed for the new employee into the Onboarding Task List. 

When the new employee falls into the defined stage, depending on how many days they are from their start date, the different tasks will be automatically added into the Onboarding Task List and notify the employee assigned to each task that they have new onboarding tasks to complete. The email includes a link leading directly to a view of their tasks. Users can sort/filter their view at their convenience and check a box to mark tasks as complete when done.

Building the Workflow

DMC builds this custom workflow using Microsoft Power Automate combined with SharePoint. There is no custom code. We only use the features that come with both Power Automate and SharePoint. The structure of this workflow works great for any company that is looking to streamline the process of onboarding their employees.

Learn more about our Digital Workplace Solutions and contact DMC today for help implementing your own workflow process!

The post Onboarding Employees with SharePoint and Power Automate appeared first on DMC, Inc..

Templates

Both tools have templates available out of the box to get you started.

SharePoint:

Monday:

You can choose to work from a template or start with a blank list with either tool. Let’s go over some basic features that you might be looking for:

Adding/Modifying a Column

You can easily add a column directly from either user interface. Previous iterations of SharePoint required configuration knowledge to set up a SharePoint list. With the modern list, a lot of settings are easily found on the user interface. You can also move around columns and change their size in both tools easily.

SharePoint:

Monday:

Adding Comments

Both tools allow you to easily thread comments regarding a specific item and tag users; however, in SharePoint Lists, since your users are already present in the Office 365 suite, they will be more likely to have the ability to access your list. The SharePoint user experience notified us that Natalie did not have access, and allowed me to grant it to her.

SharePoint:

Monday:

Version History

This is used if you want the ability to see how the item has changed, who changed it, and when you would utilize the version history.

SharePoint:

Monday:

Many other features have parity between the two:

• Custom permissions levels and access for internal and external users per board
• No code is required for automations (send emails on triggers, update items)
• No code forms for inputting data
• Data visualization within a click of a button
• Creating views with filters, sorting, and summing
• Bulk or Batching Editing
• Attachments

When you complete your board, you will have a professional-looking board that you can use for a variety of purposes.

SharePoint:

Monday:

So, Why Choose SharePoint?

SharePoint is a great software tool to use for integration with other Microsoft platforms. You are already in Office 365, so you can easily integrate your data, documents, and users right into the boards without additional configuration. For example, Microsoft Teams integrates with Microsoft Lists seamlessly, so you can keep the conversation and the items in the same user interface.

You can hover over an individual and automatically pull in their photo, contact information, title, and other important information right from Active Directory without advanced configuration, since we are in the Office 365 suite.

Depending on how many columns you have, you might need to display them in a way that is more digestible to your users.  For example, here is an example of an onboarding process that is used to see where a new client is within the stages using advanced formatting.

Once you need SharePoint for advanced configurations that are beyond the scope of what an individual can do, DMC can help!

Customization possibilities are endless in SharePoint. Using either advanced configuration or complete custom application development, with SharePoint, anything is possible. DMC is a leading expert in SharePoint and can help with these advanced needs, like creating advanced custom forms, implementing complex workflow management, and complicated data analytics.

One of the most overwhelming differences between SharePoint and Monday is the price. Following the trial period, the price of Monday significantly increases as they use a tiered, per-user pricing method. This can become especially expensive for larger companies. Monday may start free, but it does not stay free if you want to use the platform for your business.

Regardless of how you are using either tool, you want to keep permissions in mind and think about your governance. To prevent people from editing your lists or making other changes, you should create a plan for how you are going to maintain your content moving forward.

Microsoft is always working to update the platform and keep it modern, and the added feature in Modern SharePoint Lists has brought it to the next level.

As a Microsoft Solutions Partner, we pride ourselves on our SharePoint expertise and want to help you organize your company’s information in the best way possible.

Learn more about DMC’s SharePoint expertise and contact us today for your next project.

The post Monday versus SharePoint Lists appeared first on DMC, Inc..

What is @pnp/sp?

@pnp is an open-source library that can be utilized in JavaScript, NodeJS, and SharePoint Framework projects to accomplish many things that we would need to write custom REST requests for. @pnp/sp pertains specifically to SharePoint and is one part of the @pnp collection. 

Why Use @pnp/sp?

Using a library is advantageous because it abstracts the REST queries and puts them in readable, understandable code. We also get the benefits of type-checking as @pnp returns defined objects, as well as abstracting some of the nitty-gritty of REST Requests away.

Simply put, @pnp/sp makes performing requests a lot easier and should be utilized if available. A major advantage of this library is that it also offers IntelliSense, a robust code-completion aid developed by Microsoft. This means we can quickly see many different properties and methods, as opposed to looking up every single command and object in the documentation.

For example, VSCode IntelliSense allows for autocomplete in the image below.

It also shows the annotated documentation for functions.

Examples and Use Cases

1. Retrieving a List of Site Users From SharePoint

Let’s say we need to retrieve a list of all users for a given SharePoint site. We can utilize the @pnp/sp/webs in conjunction with @pnp/sp/site-users to retrieve a list of siteUsers for a given site:

const users = await web.siteUsers();

const usersFiltered = await web.siteUsers.filter(`startswith(LoginName, '${encodeURIComponent("i:0#.f|m")}')`)();

2. Getting the Current User’s Groups

We can use @pnp/sp/site-groups to easily find, delete, update, or even add a site group to a user. In this example, we’ll retrieve a list of groups the current user belongs to.

As we can see in the IntelliSense, it provides us with some properties of each group, such as ID or description, which we can then use for our code.

3. Adding a File to a Folder in SharePoint

If we need to add files, we can do so by first using a combination of @pnp/sp/folders to navigate to the folder we want to use. Once we’ve found the correct folder, we can simply use @pnp/sp/files to add the files.

const result = await web
                    .getFolderByServerRelativeUrl("https://myExample.sharepoint.come/myFiles")
                    .files.add("MyNewFile.txt", file, false);
                return result;

These are three basic examples of some common use cases in development. However, there are plenty of other libraries in @pnp/sp that can achieve many things that we would otherwise have to create our own queries for. @pnp/sp is a great resource with a wide variety of functionalities offered to SharePoint Framework developers. I suggest visiting their documentation for more examples and uses of this library.

Learn more about DMC’s SharePoint expertise and contact us to get started on your next project.

The post Easily Access SharePoint Content Using @pnp/sp appeared first on DMC, Inc..

You may have heard the news on July 6, 2020, that SharePoint 2010 workflows are being retired this year, and likely have a lot of questions. If you are hearing this news for the first time, below is an excerpt from Microsoft’s official announcement.

• Starting August 1st, 2020, SharePoint 2010 workflows will be turned off for newly created tenants.
• Starting November 1st, 2020, Microsoft will begin to remove the ability to run or create SharePoint 2010 workflows from existing tenants.
• Starting November 1st, 2020, SharePoint 2013 workflows will be turned off for newly created tenants.

If you are not familiar with SharePoint Online tenants and how they work, you may have some questions.

What do these dates mean?

If you are currently using SharePoint Online (Office 365), starting on November 1st, 2020, SharePoint 2010 workflows will stop working. While it may not happen on the first of the month, all tenants will be affected eventually. Microsoft rolls these changes out gradually rather than all at once, and eventually, all tenants are affected, regardless of size.

If you are using SharePoint on-premises, you will not be affected. However, if you are considering migrating your on-premises SharePoint implementation to Office 365, or implementing SharePoint Online for the first time, any tenants created on or after August 1st, 2020, will not have the ability to create or run 2010 workflows. If you are migrating to SharePoint Online and have SharePoint 2010 workflows, you will need to replace them.

Will this affect my SharePoint Sites?

To answer this you must answer two questions.

1. Are you using SharePoint Online or SharePoint on-premises?
   If you are using SharePoint on-premises, then you will not be affected by this change, although you should still consider a migration plan, as what is implemented in SharePoint Online will inevitably follow to the on-premises versions of SharePoint. If you are using SharePoint Online, you may be affected by future changes.
2. Do you have any SharePoint 2010 workflows?
   If you aren’t familiar with what type of workflows you use, you can check using Microsoft’s SharePoint Modernization Scanner. It will scan your SharePoint sites and detect the usage of any legacy workflows, including both SharePoint 2010 and 2013 workflows.

If you are using SharePoint Online and are running any SharePoint 2010 Workflows, you will be affected by this change.

I have 2010 workflows on SharePoint Online what should I do?

The short answer is that you will have to replace them.

The preferred platform to replace SharePoint workflows is Microsoft’s Power Automate. This offers a variety of benefits over using SharePoint workflows and can replace all the default functionality of SharePoint workflows. If you have extended SharePoint’s functionality with custom actions, you should review the available actions in Power Automate to duplicate these actions.

What about my SharePoint 2013 workflows?

As of right now, these workflows will continue to work as intended. They are considered “supported” but are also considered “deprecated”, which means no new features are going to be added to this service. In addition, any tenants created on or after November 1st will not have 2013 workflows as an option. This can be turned on using PowerShell if required.

How can DMC help?

This process can be daunting. Developing a plan of action and relying on experts with Power Automate experience will be invaluable in this time of transition. Our team will:

• Analyze your SharePoint site and prioritize workflows that must be rebuilt
• Determine if the processes that your 2010 workflows support should be rethought or redesigned
• Architect and design your workflows 
• (Re)Build workflows using Power Automate (a.k.a. Flow) 

DMC has a wealth of experience with migrating and building new Flows in Power Automate to manage, automate, and streamline business processes. Please contact us if you need assistance migrating your existing workflows or building new workflows to improve your business processes.

The post The Retirement of SharePoint 2010 Workflows appeared first on DMC, Inc..

With so many tools available, we recommend that our clients plan their project management approach in advance. We help them discuss your internal and external needs and think through how to best utilize the Office 365 offering. 

In this video, I cover the pros and cons of the various ways to store project documents in Microsoft's Office 365 cloud platform. I compare Microsoft Teams vs. SharePoint and using libraries vs. metadata. I will also review some best practices and pro tips for planning project management tools effectively.

Learn more about using Teams and SharePoint for project management. 

The post Comparing Microsoft Teams vs. SharePoint for Project Management appeared first on DMC, Inc..