Verified on Sprint testing environment, see results below:
Error message is updated on UI side to: “Fail: Indicator must contain one character and can only accept numbers 0-9, letters a-z or a '\'.”
”\” sign or “<whitespace>” are used as undefined indicators on UI.
See attached screenshots:

Open

On back-end side (MARC validation rules configuration) “#” sign is used as undefined indicator code.
See attached screenshots:
Attempt to create Indicator code using “\” sign:

Open

Attempt to create Indicator code using “#” sign:

Open

Conclusion: during MARC validation rules configuration, users will need to use “#” sign to create/update undefined indicator code.
On UI side (in quickmarc) only “\” sign and <whitespace> could be used as undefined indicator code. “\” and “<whitespace>” on UI are equal to “#” in MARC validation rules.
Hey @Khalilah Gambrell - please review if it’s acceptable.

@Pavlo Smahin and @Valery_Pilko - I updated the user story.

@Khalilah Gambrell
We don’t make any changes to how SRS stores indicators. Undefined indicators are stored as ' ' in SRS.
Please provide details where Bulk-edit, Data export and Data import use '\'

Do you suggest supporting both # and \ in quickMarc UI as Undefined value and then convert it to ' ' when we save a record to SRS?

Regarding # why not allow it to be an acceptable character? I am not trying to be difficult but I do not want a situation where folks are currently using # and then we now disallow it.

@Khalilah Gambrell - thank you for clarification, @Pavlo Smahin then I suggest
1) to change error message to not confuse users:
from “Indicator must contain one character and can only accept numbers 0-9, letters a-z or a '#'.
to “Indicator must contain one character and can only accept numbers 0-9, letters a-z or a '\”.
2) If “#” is entered from UI in ind box, we should return the error.