Skip to main content

Requirements for Marketplace app

Level: intermediate

Requirements for compatibility​

  • Implement compatibility with the Microsoft SQL and PostgreSQL databases for new Marketplace apps. Implementing compatibility with the Oracle database for Marketplace apps is optional.
  • The Marketplace app must support .NET Framework. .NET Core and .NET 6 support is optional.
  • Implement compatibility with the latest Creatio version of the Marketplace app.
  • Implement compatibility with the existing Marketplace app updates with the previous app version.
  • Describe all implemented corrections and modifications when you release the new version of the existing Marketplace app.
  • The Marketplace app must be compatible with base Creatio products and versions. If you use the Studio Creatio platform as a base product, the Marketplace app is compatible with all base Creatio products.
  • Support all versions of the Marketplace that the users use with actual Marketplace app licenses or the paid support package.
  • Use the file management API in your Marketplace app instead of direct SQL queries. The API lets you access files stored in the database and external storage. Learn more: API for file management.

Requirements for package​

  • Release the Marketplace app as a single Creatio app and/or setting in an external app.

  • Fill out the Marketplace app properties before delivery.

  • The Marketplace app functionality must be stored in an assembly package. Learn more: Assembly package.

  • Deliver the implemented customization as a package. Do not customize Creatio beyond the configuration, for example, create or change files in the Creatio file system.

  • The Marketplace app functionality must include the unique prefix of the app developer. Learn more: Development tab (Developer prefix property). Do not develop a Marketplace app without a prefix or with the Usr prefix.

  • The Maintainer package property must include the maintainer specified in the public profile. Learn more: Development tab (Developer maintainer property). Do not develop a Marketplace app using the Customer maintainer.

  • Upload the Marketplace app as a *.zip archive that contains one or more *.gz packages.

  • Add all *.gz package archives in the root folder of the *.zip archive. Do not use subfolders.

  • Name the *.zip archive based on the following template: Marketplace-app-name-Version.Number.

    View an example that names the *.zip archive of the custom Marketplace app in the table below.

    Salesloft-connector-1.15.zip

    Salesloft_connector_01.06.2022_10_16.zip

Requirements for app properties​

  • Do not use the base properties template generated automatically.

  • The Please name your application field value entered when creating the app must match the app name on Creatio Marketplace.

  • You can select any icon in the Select icon and color block or use custom icon. The icon must match Marketplace app functionality.

  • You can select any icon color in the Select icon and color block.

  • The Version app property must be numbered following the X.Y.Z format, e.g., 1.0.25.

  • Update the Version app property for each new release.

  • The Maintainer app property must include the maintainer specified in the public profile. Learn more: Development tab (Developer maintainer property). Do not use the Customer maintainer.

  • If you use custom icon for the Marketplace app, make sure the icon meets the following requirements:

    • Format: *.svg.
    • Size: 32x32 pixels.
    • Style of icon: a flat white minimalist image, rounded corners.
    • Style of icon background: background must be transparent.
    • Recommended line width of icon: 2 pixels.
    • Focus is on the center of the icon.
    • The icon matches Marketplace app functionality.
    • The icon detailing matches the other icons.

Requirements for localization​

  • English version is mandatory.

  • Translations to other languages are optional.

  • Translate the following elements if users can use the Marketplace app in other languages:

    • app UI, for example, sections, details, fields, dashboards, notifications, etc.
    • localizable strings
    • bound data, for example, lookup values, demo data, system settings, etc.

  • Translation of system data is optional. For example, headings and elements of business processes, headings of objects and schemas, and log data.

Requirements for front-end​

  • New Marketplace apps must be developed in Freedom UI. Freedom UI sections can include Classic UI section counterparts.

  • Pages and sections of Marketplace apps in Freedom UI must not include any Classic UI elements.

  • Existing Marketplace apps developed in Classic UI can be updated on the Creatio Marketplace without migrating to Freedom UI.

  • Requirements for the icon of the Marketplace app section are as follows:

    • Style: a flat white image without small elements or lines, background must be transparent.
    • Format: *.svg.
    • Size: 32x32 pixels. Note that the required icon size without border margins is 24x24 pixels.
    • We recommend selecting an icon of the Marketplace app section from the section icon library.

  • User task icons must follow the Requirements for user task icons.

  • Requirements for the UI element name are as follows:

    • Capitalize only the first word of the UI element name.
    • Capitalize only the first letter of the "Id" abbreviation or a proper name in the field name.
    • Do not use CamelCase or Title Case in the UI element names. For example, UI element names that have the customFieldName or Custom Field Name pattern are prohibited.

    View the examples of custom field names in the table below.

    Custom field name

    Custom Field Name

    CustomFieldName

    Employee Id

    Employee ID

    John Smith identifier

    John Smith ID

  • Use the basic page and navigation elements of the Creatio instance for the Marketplace app interface. For example, fields, buttons, tabs, etc.

  • Enable the user to use the base Creatio functionality in its original form, whether implementing the new functionality or extending the basic Creatio functionality in the Marketplace app.

  • Follow these principles when you develop the Marketplace app functionality:

    • Clarity. Develop a clear and logical interface to help users orient in the Marketplace app. Name UI elements as calls to action, for example, add, upload, etc.
    • Consistency. Design the app functionality so that it solves a specific business problem in its entirety as opposed to improving the experience of an individual functional or organizational role.
    • Specificity. Let the user use the additional technology implemented in the Marketplace app, for example, keyboard and mouse input, touch input, etc.

Requirements for functionality​

  • Use the Marketplace app to solve a business task that cannot be solved with the basic development tools, or this solution is time-consuming or optimizes the business task solution.

  • Do not duplicate base Creatio functionality in the Marketplace app. If the Marketplace app extends base functionality, use existing Creatio functionality.

    Examples that comply with the requirement:

    • Extend the CTI panel tab functionality of the base communication panel that is used for the call management during the new telephony connector development.
    • Extend the Chats tab functionality of the base communication panel used for the chat management during the new chat connector development. You need not develop a UI that displays chats.
    • Develop a custom contact action and add it to the Actions button menu of the contact page toolbar. Replacing the CSS styles and developing the new button in another place on the contact page are unnecessary.

Requirements for licensing​

  • Paid Marketplace apps must be licensed.

  • Licensing must restrict the usage of the base functionality in the Marketplace app.

  • The name of a licensed operation must include the prefix specified in the public profile. Learn more: Development tab (Developer prefix property).

  • Set up licenses based on the rules in the table below.

    Licensed element

    Licensing requirement

    Limitations

    Licensed objects

    The objects of a custom section must be licensed.

    Maximum number of licensed elements: 20.

    Key objects that contain active data changes must be licensed. Object that has static data must not be licensed. For example, lookups.

    Licensed operations

    If the package does not contain licensed objects, licensed operation is required. Otherwise, licensed operation is optional.

    Important

    Do not use personal and server licenses that control the same objects and operations at the same time.

Requirements for security​

  • Make sure the Marketplace app settings related to information security meet the Recommended information security settings (user documentation).

  • The Marketplace app must not decrease Creatio performance.

  • The Marketplace app must follow information security best practices. Use the recommended API Creatio calls in the Marketplace app. Ensure that Open Web Application Security Project (OWASP) Top 10 vulnerabilities are absent in the Marketplace app. Do not use components with known vulnerabilities. Learn more about vulnerabilities: official OWASP website.

  • The Marketplace app must follow content security policy. Learn more: Set up content security policy (user documentation).

  • Use the law way to get data access, and do not send data from the Creatio instance in the Marketplace app. Describe the data sending on the Marketplace app page and restrict the data sending before the user authorization when you integrate with external apps.

  • Do not use anonymous web services in Marketplace apps if other integration options are available. Instead, integrate the Marketplace app with an external app using webhooks or web services that use OAuth 2.0 authorization. If secure integration options do not let you solve all business problems, you can use anonymous web services as long as you meet the following requirements:

    • Implement verification of incoming requests. For example, use an access token.
    • Do not transfer confidential information via an anonymous web service.

    Marketplace apps that use anonymous web services have higher publishing time since the security department must review the anonymous web service.

  • Do not use external libraries from unknown sources in the Marketplace app.

  • Deliver Marketplace app functionality as packages that are not linked to external repositories. For example, NuGet, npm, CDN, etc. Add the entire set of JS and CSS files that include the complete source code of the app functionality to the packages. Implement and test the app on a single Creatio instance. Use an external connection that is described in the app documentation on the Creatio Marketplace only for data exchange.

  • Use package install scripts to execute CRUD operations with data as part of the package installation process instead of SQL scripts. Install scripts execute operations with data using the Entity class. Learn more: Customize delivery process.

  • Do not use the Terrasoft.Core.DB.CustomQuery class. This class is deprecated and will be removed in upcoming releases.

  • Encrypt sensitive data such as API keys, API secrets, passwords, access tokens, refresh tokens etc. and store them in the Encrypted string field. Learn more: Set up secure password storage.

  • If you use the Encrypted string field on a Creatio form page, implement custom front-end logic to hide the field value on a page.

Requirements for demo records​

  • The number of section records must provide enough data for nice-looking analytics (20 on average).
  • The first three section records must be showcase records.
  • You can add up to 1000 demo records to the corresponding database table.
  • Record data must be logically consistent.
  • Demo data must be relevant for the target audience and region where you are going to distribute the app (addresses, names, phone numbers).
  • Each section record must be unique. The record variety must be reflected in folders and analytics.
  • Use records that are logically related to records of other sections. We recommend creating record chains instead of going from section to section.
  • Bind the demo records to base demo data for data integrity.
  • Add demo records not only to sections, but also feed records, reminders, notifications, emails, comments, likes, etc.
  • Demo data must have a positive message.
  • Demo data must be in English.
  • You can fill out lookups using either softkey or demo data.
  • Lookup records must be unique.
  • If Creatio must add the corresponding activities when you add demo records, verify that the records are present in the activity schedule.
  • If demo data must include dashboard analytics, verify the charts in each section and take the update date into account.
  • Some sections use pre-configured filters by owner and period, for example Activities, Invoices. Ensure the section list includes demo records that match the filter conditions.
  • Implement a demo mode for connectors. You can do it using pre-configured test users or a simulated integration that showcase how the connector operates.

See also​

API for file management

Assembly package

Steps to publish a public profile

Steps to publish the Marketplace listing using Creatio Marketplace Console

Configuration elements of the User task type

Recommended information security settings (user documentation)

Set up content security policy (user documentation)

Customize delivery process

Recommendations for front-end development of a Marketplace app

Resources​

Section icon library

Official OWASP website

Marketplace updates