Adding New Choices for Approval Table

[CJB]

Hi everyone. I have a request to rename state choices (Approved, Rejected, etc) in the Approval table. The issue is that this is a scoped application, so I don't want to affect the naming for the rest of the system. So, my question is how should I implement this request?

• A new Approval table in the scoped application: Approval doesn't seem to be extensible though. Would I just need to toggle that to true and extend? Otherwise, I feel like I would need to replicate all the out of the box scripts that go along with the Approval table.
• Add new choices to out of the box Approval table: I don't want these fields to display in global though. It should only be the scoped app.
• Business rule: I don't know if this is entirely possible, but could I rename all the labels before the approval is created for the change request? Seems like this could be tricky.
• Other: If there's another way to resolve this, I'm happy to hear it!

Thank you.

[Willem]

Hi CJB,

Not sure what your requirement is. If approval is needed, Approved, Rejected and Cancelled are not generic enough to support your process? If this does not fit, I would not try and customize the Approval table/functionality. Also rebuilding would not be advised.

With that in mind going through the list:

• A new Approval table in the scoped application: As the table is not extensible, I would not change this. Also rebuilding the same functionality does not seem like a good solution.
• Add new choices to out of the box Approval table: This will impact all other approvals as well.
• Business rule: In general any 'trick' with scripts I would be very careful with in this case. Approvals are an important part of any governance and scripting a workaround will affect this.
• Other: Please share your requirement. Maybe something like a State change of the record allowed by only certain personas could suffice? If you can share more info, possibly we can come up with an alternative solution then Approvals?

[CJB]

Hi Willem,

Thank you for your response. A separate group at my company is utilizing our system, but in a scoped application. Due to their business processes, users in this group have already been using "Agreed" and "Disagreed". All of their documentation would need to be updated to reflect "Approved" and "Rejected", which they do not want to do. The underlying value would still be Approved and Rejected; they just want a rename for the labels.

Meanwhile, in Global, all of our approvals have been using the labels Approved and Rejected for years, so we do not want to rename the labels across the system.

Thank You,

CJB

[Willem]

Hi CJB,

Thank you for clarifying. Where are they using the Agreed and Disagreed? Is that on the portal and in email? Then you could make a specific (scoped) widget showing the buttons Agreed and Disagreed. Same can be done in emails.

If they use the back-end view, you might want to think about maybe presenting them with UI Actions named Agreed and Disagreed and then using the default approvals in the background.

Keep in mind, those are work-arounds on the visual representation. The data (and therefore reporting) would still show Approved or Rejected f.e.

Hope this gave you some inspiration 🙂

[CJB]

Thank you. I think the largest issue is for (group) approvals lists and UI actions. UI actions I think will be straightforward, but I'm stumped on the lists since there doesn't seem to be an easy way of dealing with it.