The adventure continues, in this episode we’re meet with a submission error I have never seen before.
This is part 3 in documenting the process of submitting an app to AppSource. If you haven’t seen part 1 and 2, you can find them here.
In this third installment of the “Let’s Put an App on AppSource” series, Erik discovers that his submission from Part 2 didn’t pass certification after all. He walks through the certification failure report, explains the issues he encountered, and shows how to fix them and resubmit.
The Morning After: Certification Failed
At the end of Episode 2, Erik went to bed thinking everything was perfect. Unfortunately, that turned out not to be the case. An email notification arrived indicating that the submission had failed, prompting a return to Partner Center to investigate.
In Partner Center, the app’s status showed that several steps had completed successfully:
- Automated application validation — passed
- Finalize workflow — passed
- Test drive provisioning — passed
- Lead management — passed
- Preview creation — passed
- Publisher sign-off — passed
- Certification — FAILED
The Certification Report: Three Failures
The certification report revealed three failures that blocked the app from being published to the marketplace. All three fell under “Value Proposition and Requirements.”
Failure 1: Inaccurate Title — Special Characters Not Allowed
The original app was named “OpenRates.io Exchange Rates,” and the listing title was “OpenRate.io Exchange Rates.” The certification report stated that special characters are not allowed in the listing title or offer name. The offending character? A simple dot (period).
Erik noted that across more than 10 apps published on AppSource between himself and eFocus, this was the first time he’d ever encountered a rejection due to a dot in the name.
Failure 2: Insufficient Description
The offer description was flagged as not being concise enough — or more accurately, it was too concise. The hasty two-line description written while tired at the end of Part 2 wasn’t going to cut it. The certification guidelines require a more complete offer description that includes a good understanding of the value proposition.
A Note on Microsoft’s Own Documentation
Looking at the commercial marketplace certification policies, Erik found the naming guidelines for Business Central apps. Two naming structures are allowed:
- Your Offer Name for Microsoft Dynamics 365 Business Central — e.g., “Sales and Inventory Forecast for Microsoft Dynamics 365 Business Central”
- Your Offer Name — e.g., “Sales and Inventory Forecast”
The documentation explicitly states: “Do not use special characters such as ampersand.” And apparently, a dot is also considered a special character in this context. Erik couldn’t help but point out that Microsoft’s own examples in the documentation arguably violate their own rules — an amusing irony.
Fixing the Issues
Renaming the App
The first and most important fix was removing the dot from the app name. Remember: the name in the app.json file and the name in the marketplace listing must be the same. Erik decided to rename the app from “OpenRates.io Exchange Rates” to simply “Automatic Exchange Rates.”
This required going back to the source code, updating the app name, and triggering a new build. What seemed like a simple rename turned into a multi-build process:
- Version 11 — First attempt at renaming, but the build system also needed the name updated
- Version 12 — Build system updated with the new name, but old translation files from the previous name caused build failures
- Version 13 — After cleaning up the old translation files, the build finally succeeded
This is a good reminder that when you rename an app, leftover translation files (`.xlf` files) referencing the old name can cause compilation errors. Make sure to clean those up.
Updating the Description
Erik replaced the minimal two-line description with a more comprehensive one prepared off-screen, providing a proper explanation of the app’s value proposition and functionality.
Resubmitting in Partner Center
With all fixes in place, the following changes were made in Partner Center:
- Offer Setup — Updated the alias
- Properties — Updated the version number to 13
- Offer Listing — Changed the title to “Automatic Exchange Rates” and replaced the description with a more detailed one
- Package — Removed the old version 10 app file and uploaded the new version 13
After verifying everything matched — especially that the offer listing name was exactly “Automatic Exchange Rates,” matching the app.json — Erik hit Publish to send it through the certification process again.
Key Takeaways
- No dots (or other special characters) in app names. This includes periods, ampersands, and likely other punctuation. Even if you’ve never encountered this rule before, it can cause certification failures.
- Write a thorough description. Don’t rush the offer description — the certification team will reject submissions that are too brief or don’t adequately explain the value proposition.
- The app name must match everywhere. The name in your
app.jsonmust exactly match the offer listing title in Partner Center. - Renaming an app has cascading effects. Build systems, translation files, and version numbers all need to be updated. Budget extra time for this.
- Expect iteration. The AppSource submission process often requires multiple rounds. Certification failures are a normal part of the process — even for experienced publishers with many apps already on AppSource.
Summary
Part 3 of this series demonstrates that the AppSource certification process can catch you off guard with rules you may not have encountered before. A simple dot in the app name and a hastily written description were enough to fail certification. The fix required renaming the app throughout the codebase, cleaning up translation files, rebuilding multiple times, updating all corresponding fields in Partner Center, and resubmitting. Stay tuned for Part 4 to find out whether the resubmission passes — because as Erik says, “This is AppSource, and anything can happen.”
