As everyone knows, it is possible to assign regional endpoints in dev console for skill, but testing them is really time consuming, because routing is very inconsistent. Even if I am from UK sometimes requests go to US.

Another issue is making sure that all endpoints work. Only way I found to test them consistently is by switching default endpoint, with other regional endpoints to get consistent results, which takes a lot of time.

My suggestion would be, that at least in the dev console, it would be possible to not only pick locale, when testing the skill, but also which endpoint skill should hit. This would speed up endpoint testing quite substantially and help build skills faster.

For large organizations I would like the ability as a developer to create sub- developer accounts within my developer account so that I can give each of my business units/divisions/affiliates a developer account to work in without them having access to ALL dev and production skills in the account. They should only be able to see the skills they are working on, whereas anybody at the top level account can see everything. This is especially important when a developer account receives a particular agreement/protection (in this case our developer account is protected by a HIPAA Business Associate Agreement (BAA) so that we can handle and transmit protected health information (PHI)) so if I want new skills to handle PHI they have to be under the overarching developer account that has the BAA. But I have several divisions that will be working on separate skills and I don't want them to accidentally interfere with one another's skills in the dev console.

The current permissions for various roles in ASK developer console and CLI/SMAPI are very broad. Large organizations need more control over roles to effectively manage Enterprise level skills. This feature request is to give organizations the ability to configure granular level access based on the roles as shown below.

Description Administrator Marketer Developer Analyst
Create Skill Yes No No No
Delete Skill Yes No No No
Creating a new
Intent Yes No Yes No
Deleting Intents Yes No Yes No
Modify Existing
intents Yes Yes Yes Yes
Updating
distribution detailsYes Yes Yes No
Skill Submission/Publishing/Hide/
Remove the skill Yes No No No
Updating beta usersYes Yes Yes No
View Alexa Skills Kit
Earnings and Payments Yes No No Yes
Access to Analytics Yes Yes Yes Yes
Endpoints
Configuration changesYes No Yes No
Trace logs for configuration
changes on
developer console Yes No No No

As the title suggests, we were recently made aware that Account Linking cannot be removed from a skill once enabled. Not even if the skill is removed. As we do not own the login system we were supposed to implement a page which described the 3rd party login system. When we submitted the skill again we were rejected with the following reason: "Please update the account linking URI to include “nosignup=true” as a parameter for suppressing the signup portions of the Spotify page and resubmit your skill." Where is the documentation regarding the nosignup parameter? How is it supposed to work? Why cannot account linking be removed from a removed skill? These new rules (no they did not exist when we implemented Account Linking) completely broke our ability to submit updates to our skill and we were forced to create a new skill with all negative side effects.

Please add a feature to allow developers/lambda function to handle unrecognized utterances.

It is frustrating to finetune a Fallback intent to catch all the unpredictable words/utterances that a user might say to allow me to handle it using a Lambda function. If no intent is selected by Alexa, Alexa will just re-prompt once and then do nothing and say nothing after the first re-prompt.

My goal is to allow Alexa to re-prompt twice and for the third time, it can exit the skill when a user says something unrelated. Therefore, it is important to be able to catch all "wrong" utterances and store the state.