Getting Started with Building a Public Plugin
Public plugins are presented to all customers in the marketplace and are openly available for use. This document outlines the initial steps of preparing for developing a public plugin and preparing for the development kickoff call with marketplace that will help get things started.
If you haven’t established a relationship with someone from our Partnership team yet, reach out to them at email@example.com. Formalizing a business relationship can help establish a mutually beneficial dynamic and help you capitalize on the opportunities our marketplace enables.
Prepare for your plugin kickoff call with the Marketplace Team. This will be a good time to raise any open questions or request feedback. You should check off the following items prior to the call:
- Identify your full product scope for your plugin so we can guide you on choices for which Zapp APIs are best suited to your needs
- Create a request for starting the onboarding process for your developers (if it is the first time, click the “signup” button)
- Identify who will fill the roles of Product Manager and Project Manager for your plugin development.
- Reach out to Yoni Osteen from the marketplace team (firstname.lastname@example.org) to get a development kickoff call set up
- Get started at looking through our developer documentation. If you have any technical questions or a request for specific documentation that you do not see available, you can submit a ticket via the service desk.
- We’d recommend having your developers look at the getting started guide
- After reviewing and understanding the big picture, they should work on setting their local environment for the relevant platforms.
- The most popular and highly recommended plugins in our marketplace follow our recommended best practices. The following items are not required to publish a plugin, but it will make your plugin higher quality, more robust, and more broadly promoted, and it is helpful to consider these things prior to the development kickoff.
- Analytics coverage
- Utilize our analytics APIs to send analytic events, screen views, and user data through our pipeline. Any analytics providers the customer receives will automatically receive your analytic data, in context with the rest of analytics data.
- This is better than isolated analytics in a separate system as it enables analyses like funnel analysis, user path analysis, and segmenting behavior and events across different domains of the app. Make sure to document your analytics offering and reference them in your About page.
- Include automated testing
- We’ve found historically that this saves development effort down the road. At a minimum, we recommend providing automated testing for any bug fixes to prevent regressions.
- Tooltips on all configurable fields
- To optimize user experience and minimize operational support burden, we recommend adding tooltips to all relevant fields, which can be read about in the manifest documentation here.
- Keep configuration fields clean with conditional fields and grouping
- Some plugins require several configuration fields. If you provide more than a handful, conditional fields (only showing a given field when a particular configuration requirement of another field is met) and grouping are effective ways of keeping things clean and usable. You can read more about this in the manifest documentation here.
- Developer Docs
- Including developer docs in your project helps with maintenance. If you also choose to make your plugin open source, this enables others to more effectively submit enhancements and fixes.
- If provided, we recommend referencing within your About markdown, described in more detail in the Plugin Rollout Document.
- Analytics coverage
As you’re making a Public Plugin for general Marketplace use, please direct whomever handles your product marketing to our Plugin Rollout Document document so they can get started in preparing the materials needed to make you shine in our Marketplace.