Using NUX forms can cause rollback on duplicate code input
Hi all,
Our team is in the process of converting from legacy/old dashboards, to NUX and one feature that holds a lot of promise are the NUX forms (for the purposes of adding to lists). The old dashboard style made it a bit clunky for creating new list items with controls and prerequisite inputs, but the forms are definitely a step in the right direction.
However, what I've noticed from testing is that there's no control to prevent a duplicate code from being entered and triggering a model rollback.
In my scenario, the form would be used for creating a project (via a numbered list) using a unique project code, as well as a name, default subset, parent and a few other fields which for the most part works quite well.
Where this falls over is that if a user accidently/intentionally enters the same project code (which is used as the numbered list code), the model rolls back because it detects a duplicate. There's also no notification the model is rolling back so it looks like the app is spinning its wheels.
In the old UX, we had a module which had some controls (like a FINDITEM() to detect if the code already existed), but there doesn't appear to be anything in place to prevent this kind of scenario.
We could create another field for the code input and just let Anaplan rely on it's own numbered list designation, but this feels like a bit of a hack given the true unique ID in our case is the project code.
Ideally, the form should detect the duplicate, block the import and give an error/warning indicating there's already an existing record (or allow it to override the original input/parent-child relationship if deemed appropriate by the page builder/WSA).
Curious if anyone else has had a similar experience and was able to get around the rollbacks?
Comments
-
Agree with you about the forms. Big step forward. For now, I'm not aware of a way to dynamically prevent a user from entering a duplicate code on a form. I tried using DCA but to no avail. Similar to your hack idea, what I've seen to get around this is to use a numbered list and a grid (not a form) and allow the user to create n-rows, usually 1. They fill in the properties, including the project ID. You can then use Booleans to determine if the project code exists. Use a filter to in your saved view that will disallow duplicates during the import. Works very nicely.
Not as nice as the form.. Terrific idea though. If you decide to make it an idea on the exchange, I'll definitely upvote it.
There are alternatives to adding n-rows because that opens up the delete n-rows ability too. Let me know if that's of interest.
Good callout nevertheless. Thanks @luke_e
0 -
Thanks for the response @JaredDolich.
And yep, my current approach isn't too disimilar to what you suggested (using modules and views). Was hoping to remove the custom configuration and move to a cleaner add-to-list method, as the form has pretty much everything we'd want.. with one obvious exception, hah.
Will take your advice though and raise on the ideas page and see what happens (will post the link here once I've done it).
Have posted on the ideas exchange here
Thanks again
0
