Video Copilot Plugins Free

[Lucretia]

APIplugins enable Copilot for Microsoft 365 to interact with REST APIs that are described by an OpenAPI specification. With an API plugin, Copilot users can ask Copilot to not only query a REST API for information, but to create, update, and delete data and objects. Anything the REST API can do is accessible via natural language prompts.

An API plugin provides an OpenAPI specification document and a plugin manifest that Copilot uses to learn the capabilities of the API. Copilot can then decide when an installed and enabled plugin's API is suited to answer any given prompt.

For example, consider a budgets API that allows for querying and creating budgets, as well as charging expense or adding funds to existing budgets. The prompt "How much is left in the Contoso travel budget" could trigger a budget plugin, making the following API call.

Copilot uses the response from the API call to generate its response: "The Contoso travel budget currently has $5,000 in available funds. If you need to allocate funds to specific categories or track expenses, I can assist you with that as well. Just let me know how I can help!"

Copilot responds to the user, using the information returned: "The charge of $500 for Megan's airline ticket has been successfully processed. The Contoso travel budget now has $4,500 remaining in available funds. If you need to make any more transactions or require further assistance with your budget, please let me know!"

For some actions, you may want the user to confirm the details before making the API call. Plugin developers can assign confirmation dialogs to specific functions. These dialogs are defined using Adaptive Cards syntax.

Take the prompt to charge a budget. To avoid incorrect charges to budgets, a plugin can add a confirmation to that particular function. Copilot will present the dialog with the function parameters it generates, allowing the user to proceed or cancel.

When you sign in to Copilot Studio, it determines which copilots you're allowed to access, based on the license associated with your credentials. The list of copilots available to you depends on these permissions. If you don't see the copilot you wish to extend, verify your credentials. Also try connecting to the copilot itself, or try to trigger any jobs that must occur to prepare the copilot for use. See the sections detailing the authoring experience for examples.

Detailed configuration steps are covered later in the documentation. After completion, the user can publish the action for the copilot. This action is now ready for an administrator to review and approve. Once approved, the action is available to all users who have permission to use it, within that specific organization.

Once an action is published, your copilot administrator has to review and enable the plugin for use. When an administrator enables a copilot, they must also determine which groups of users have permission to use it. The location for managing permissions might differ depending on the copilot. More information is available in the administration documentation. Once activated, a plugin appears in the environment where it was created. The plugin can also be exported for use in other copilots. Exporting creates a package that can be deployed in other environments, removing the need to recreate the action for each environment you wish to use it in.

Published actions can also be submitted to Microsoft for certification. Certification is done using the Partner Center and involves a review of the action and certification by Microsoft. After that it appears in the action catalog where all users of Copilot Studio can use to extend their copilots as well.

After you have completed these steps, you can publish the action. An administrator can then review your action and activate it. Once the action is activated, you can use it within your organization, deploy it to other organizations, or submit it to Microsoft for certification, to make it available to the general public.

There are multiple input handlers and content sources available to serve as a basis for plugins. In Copilot Studio, these sources are called actions. What these different types of actions have in common is the basic structure for communicating to the details of the source when submitting queries. The following action types are available:

These actions let you connect your copilot to data or perform activities. During this preview, you can use actions in Microsoft Copilot. You can't use actions in custom copilots that you build with Microsoft Copilot Studio.

In order to use the content sources, you have to define authentication for the source. Sources require specific types of authentication. When you select your content, the source provides the needed prompts for authentication.

Each source has actions already defined, but when configuring, you can select which of the actions you wish to use. You can select from any number of actions to use with the source. For example, with multiple actions, you could perform the following:

Every action is available to users of the extension. You cannot have role based permissions for a specific action within it. For example, if you had an Order Management extension that allows for retrieving a list of records, updating an order, creating an order, and cancelling an order, then every user with permissions to that extension could take any of those actions. If you need to segment access to specific actions, you would need to create different extensions with different actions in each with appropriate security roles assigned to each plugin.

Inputs and outputs are specific to an action and provide all of the data input options possible for an action and define the results to return. These parameters are provided by the content source (connectors, and so on) and can't be added to or removed. However, descriptions can be updated to provide a better understanding of the inputs and outputs. They're displayed as part of the setup to provide visibility into what needs to be included in a query and what is returned.

Solutions are essential for application lifecycle management. If saved in a solution an action can be easily moved across environments. By default, the system selects the most suitable solution for you, based on the preferred solution, or a solution where connector components are present. You can also change solution. If you don't specify a solution for your action, the system automatically creates a solution at runtime.

User consent is a toggle provided on each action. It determines if the copilot will prompt users to continue when executing an action. Turning on this option means that the copilot will ask users if they're sure they want to take the action. This helps prevent unintentional actions that could affect data.

Conversation starter lets you create commonly used questions that display as clickable buttons. Conversation starters execute the query immediately. They also show types of queries that can be used. These examples can help users come up with more queries on their own using successful natural language framing. Conversation starters are set at the plugin level rather and are optional. You can edit them at any time.

Adaptive cards are an optional component configured at the action level. You can add or modify them at any time by editing the plugin.Adaptive cards provide an alternative way of displaying results from a copilot query.

When configuring the default adaptive card, you must select a root path. The root path is a segment of the data source's configuration file and it includes all the fields that can be selected to define the title or body. There can be multiple root paths in a source file, and all available paths are available for selection. After you select a root path, you can choose the desired title and body from lists.

Every adaptive card shows the returned values and then lists the references used when compiling the result. Adaptive cards also allow a user to specify the reference view layout. This is how the references used in the query are displayed for more information. It allows for inclusion of a title, URL, and subtitle. These are also dropdowns that can be populated based on the root path selection.

When uploading a custom adaptive card template, no edit capabilities are provided in the wizard as the custom card should already include all fields, buttons, and mapped values to be consumed by the copilot. Any field left blank in the Default template doesn't appear on the adaptive card within the copilot.

For connector actions, a maker can test the new plugin inside of Microsoft 365 by sideloading the plugin created. This is an option on the review screen when the action has been authored. It will prompt the user to select or create a connection, and then create a side loaded test version of the plugin that is available in the M365 environment. This is not visible externally and is not published for admin approval. It is only available for the author so that it can be used only to validate that the plugin is working as expected.

Integration with Copilot Studio and Power Automate is enabled by default. That means, plugins created in Copilot Studio will show up for users under "Copilot Studio" or "Power Automate" even if the tenant admins have not explicitly deployed the app for end users. This might change in future.

The number of Power platform environments enabled for integration is currently limited. Reach out to Microsoft support if you have a large number of Power platform environment (>100) and want specific Power platform environment to be enabled.

However, the action author can share their plugins in the portal where they created them. For example, you can share an AI Builder prompt from the AI prompts page by selecting Share for the prompt. The same applies for Power Automate flows (from the Flows page in Power Automate) or for custom connectors from the Custom connectors page.

3a8082e126