• State Not Answered
  • Replies 5 replies
  • Subscribers 7 subscribers
  • Views 1823 views
  • Users 0 members are here
Related Discussions
Home » Discussions » General

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

paulc919
I'm currently developing a reference maintenance function and wondered if anyone had already done something similar ? The rationale is that we can give maintenance function to trusted Business reps so they can maintain the reference data used in Appian processes or exposed to other systems, things like Pension Annual Allowances (changed by UK Government), Document Hyperlinks (changed as and when the URL is amended).

I'm currently using a combination of Records and related actions to Add or Edit entries (as per the attachment) and wondered if this approach is a good idea or if there are some existing patterns I could plug into ?

Thanks

Paul

Reference Data Maintenance.docx

OriginalPostID-198324

OriginalPostID-198324

  Discussion posts and replies are publicly visible

  • 0
    A Score Level 3
    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.
  • 0
    Certified Lead Developer
    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.
  • 0
    Certified Lead Developer
    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.
  • 0
    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.
  • 0
    Thanks for all your comments - glad to know I'm on the right lines :-)

© 2024 Appian. All rights reserved.