I'm currently developing a reference maintenance function and wondered if an

RE: I'm currently developing a reference maintenance function and wondered if an

paulc919 — Wed, 09 Mar 2016 18:32:54 GMT

Thanks for all your comments - glad to know I'm on the right lines :-)

RE: I'm currently developing a reference maintenance function and wondered if an

Chris — Wed, 02 Mar 2016 21:59:54 GMT

We do this as well, wherever possible. Similar to the considerations above, I will often record 2 data bits for any field selection where options are editable by our functional owners - one for the chosen ID of the entry/option, and one for the value at selection time. This allows you to display the option as shown at task completion time, as well as retaining the ID for situations where you may want to display currently updated data, vs what it was during selection - depending on process considerations. Different types of data will require different theory there.

RE: I'm currently developing a reference maintenance function and wondered if an

ChristineLHutchison — Wed, 02 Mar 2016 17:09:05 GMT

I do this in jut about every project for data that does not affect process flow (meaning a model change would not be needed). It is important to allow for Lookup data to be changed, outside a release.
Some gotchas:
1) Never allow deletes, only deactivates otherwise you break referential integrity
2) Make sure when processes start, they pull active only, but edits or post selection pulls the inactive incase it was selected

I usually have an action, that gives them a TOC of all the data that they can edit (names, descriptions). Then upon selecting one, the data that can be changed. The record works too. I just do this, cause it is one screen, one place, less clicks to find and act.

RE: I'm currently developing a reference maintenance function and wondered if an

PhilB — Wed, 02 Mar 2016 15:20:28 GMT

Definitely something that's worth pushing over to the business, but it's very important to consider the effects changes on reference data can have - for example, what will a change do to in-flight instances and should completed instances be referencing the "old" or "new" data?

Often it's a requirement to record exactly what the user saw in their tasks, so overwriting reference data is inadvisable. Instead, logically delete an entry and add a new one so that the data can still be referenced by older instances and the history is preserved.

RE: I'm currently developing a reference maintenance function and wondered if an

Stefan Helzle — Wed, 02 Mar 2016 12:33:22 GMT

I always try to push this in our projects because I think that functional application maintenance should not be done by IT staff. Just make sure that all actions are logged and add an approval step if necessary.