Currently, flags are not allowed to be edited after creation.
I understand that it should not be possible to delete them or change their meaning, after they have been used.
Is the editing of custom flags planned but not yet implemented?
Definitely need this option added to the web interface.
To be clear since this was moved. I was not referring to Edit. But the option to have a flag trigger auto hide without using console rails.
The way custom flags has been designed currently, it is still possible to edit them after they have been created. However, once they have been used they can no longer be edited. But they can be disabled and replaced with another flag.
There is a notice along these lines on the flag editing page:
Once a custom flag has been used, it can only be disabled but not edited or deleted.
Could you elaborate, why further editing is not allowed?
Changing the description (for example for clarification) should not harm any behavior.
Likely similar to voting
It seems, there are two different views on this kind of problems: a) don’t change history b) let’s hack(improve) it, until it works.
It’s about consistency. For now there is no plan to change this behavior. So if you need to make a change to one of your custom flags after it has been used, you want to follow what that prompt says and disable the flag and create a new one.
Most sites do not need to make any changes to the flags at all - and for those that do the expectation is not that they will be changed much if at all once they are being used.
Ok. So I will use the console to adapt the text.
We are using a flag “shares private information” while trying to educate users, not to answer publicly (mostly by mail), if they want to reach an author of a message.
In this process, we will have to adapt texts.
But for
the limit of 50 flag reasons is not that much.
What about using the option to add extra details after choosing flag? Similar to Something else flag?
Then every person helping to keep the forum free of personal messages via flagging would have to write the educational text for the uneducated user, which will not happen.
That’s the power of open source! 
But of course when you do that you are on your own and it may become harder for you to get support from us. But you know that already. We do recommend disabling and creating new flags instead of changing them via the console, once they have been used.
This is just a hidden setting and can be increased. Folks on our hosting that are bumping up against that limit can reach out to us to increase it for them. It will also be interesting for us to hear from customers about how they are using the custom flags and why they might be needing to make so many changes!
Sounds like maybe need a plugin or something then to extend custom flagging.
Otherwise maybe template plugin with additional work of mod sending a pm..
Or alternatively maybe a custom automation script maybe for a pm?
I think this restriction is quite limiting to use the Discourse software in more advanced public project workflows, where you want to have more specific rules, but still to be open for the audience which is not educated about them.
Custom flags with proper descriptions and links to relevant help articles is currently the easiest way to communicate to the user the expectations and rules of the current forum. Unlike the separate docs with a large list of rules, the flag description is visible exactly when needed and to those who need it - both people who set the flag and to those who receive it. Flags is the Discourse super-power from what I am seeing.
For example, in our case we need to clarify to a user that some areas of the forum have much more strict definition of what constitutes as offtopic and generic off-topic flag is not good enough for it. (Basically every use of the system flag with Off-topic label currently triggers a reply - “but this is not an offtopic” and we have to have a personal conversation about why it is off-topic under this specific constraints.)
I would create the specific “Does not fit the workflow” flag with a proper description for that case and a link to the workflow documentation. I would iterate and tailor the messaging on the flag, as the description needs to evolve together with the evolution of the underlying workflow.
But because you don’t allow to edit it, I can not even fix a typo, not talking about more elaborate explanations even.
I understand the “don’t change the history” concern, but there are ways to workaround it: for example make only the description field editable; or add a new editable “doc/help” field; or add a new version field to the flag and bump it on edits, so it is visible that the post was flagged with previous version… etc
P.S. Does the limit on 50 flags count also the disabled flags? If yes, and I both can not delete disabled flags and can not edit them, then flags is a limited non-renewable resource which is not sustainable for any long-term setup.