×

    Filters

    Didn't find what you were looking for?

    Extend your Search in Community

    Questions?

    We're always happy to help with questions you might have. Contact Us

Results

Exchange Certification

   Exchange This topic is related to the Avoka Exchange.  |   Platform Developer |  v5.0 & Higher   This feature is related to v5.0 and higher.

During the Exchange Publishing Process you will be required to get your package certified before it can be made active on the Avoka Exchange. When you submit your package for certification it will be added to the work queue for the Exchange team and scheduled for review. This review may take up to 6 weeks and may require one or more scheduled conference calls between the certification team and your project team to discuss aspects of your solution.

The Exchange team will review your package to ensure that it meets certain standards and minimum requirements in terms of how it is designed and built. We consider many aspects of the solution you've produced, including those listed under Certification Checklist below. We encourage you to become very familiar with this checklist and ensure that you are considering these items from the outset of your project so that delays are minimized when you wish to publish your solution on the Avoka Exchange. If anything is uncertain it is better to seek clarity before submitting for certification than it is to submit a non-compliant solution and receive a certification failure.

When you submit your package for certification it will be added to the work queue for the Exchange team and scheduled for review. This review may take up to 6 weeks and may require one or more scheduled conference calls between the certification team and your project team to discuss aspects of your solution.

Certification Checklist

Before submitting your package for certification, ensure you have reviewed the following checklist:

  1. Project pushed to Exchange GIT Repository.
  2. Adequate Package Documentation.
  3. Security of Customer Data.
  4. Language Translation Support.
  5. Package Compatibility Requirements.
  6. Unique Asset Naming Strategy.
  7. Best practices used as per Groovy Coding Conventions & Practices, in particular:
    1. Naming Conventions for Groovy Services.
    2. Logging Third Party Service Calls.
    3. Encapsulating Common Code in Shared Groovy Classes.
  8. Maestro Library named exchange.<project-name>
  9. Maestro Component Design Considerations:
    1. Responsive design - make sure it looks and behaves appropriately on all screen sizes.
    2. Data Binding and no binding where appropriate.
    3. Can be used more than once in a single form, and in repeats with no duplicate binding issues.
    4. Receipt presentation considerations - how should this appear on the receipt?
    5. State retained between save and resume events.
    6. Rule templates - consider adding rule templates so users of the component can add code for specific triggers.
    7. Rule helpers - think about right click menu and any features to expose.
    8. Ensure no errors in JavaScript console during use.
  10. Journey Analytics Considerations:
    1. Insights Field Names configured in Maestro to override original field names and add clarity to duplicate field names shown in Field Analysis View.
    2. Journey Analytics Milestones (e.g. GreenID VERIFIED) - test that they are being sent.
  11. Sufficient test cases to cover usage scenarios.
  12. Review of TODOs.
  13. Demonstration form provided in Maestro project.

Certification Report

At the completion of the certification review you will receive a report detailing the outcome of the review and feedback relating to the areas highlighted by the review team.

The report will detail the overall outcome of the review (CERTIFIED or UNCERTIFIED) and may contain a number of feedback items classified as either:

Comment - A benign note made by the certification team relating to your solution. Comments to not impact the outcome of the review;

Recommendation - A suggested (but not required) modification to the solution that should be considered by your project team; or

Requirement - A mandatory requirement that must be satisfied by your solution before it is certified. The presence of any such items will result in an UNCERTIFIED outcome.

Any solution that does not get certified on the first submission may be resubmitted once the feedback items have been addressed.