Solved

What is the added value of using a subroutine procedure instead of a task without table task?

  • 9 February 2021
  • 1 reply
  • 48 views
E
Rank
Userlevel 6
Badge +16

In the SF you can create a subroutine procedure to create a non-gui task. However, you can also create a task and not create a table task for it. I was wondering in what situation one would use a subroutine procedure over a task without a table task? 

When using subroutines there are some disadvantages. There are 2 places you need to maintain the logic (in tasks and in subroutines). Functionality can not be shared between tasks and subroutines. Subroutines can not be added to the gui or a process flow. This sometimes leads to new placeholder tasks to give the subroutine some GUI functionality. 

So therefore i'm wondering what is the added value of the subroutine procedure?

icon

Best answer by Vincent Doppenberg 9 February 2021, 14:19

View original

1 reply

V
Rank
Userlevel 6
Badge +4

Hello Erwin,

There are a few advantages:

  • You're right that you can make a task unavailable and that, from a GUI perspective, it would be the same as a subroutine. But it is a lot harder to ensure that none of your end users have access to a task than simply not creating a table task for it. The only way to really ensure it is by removing permissions to it across all roles and making sure that the permissions stay that way. Don’t forget that tasks can also be
    • a menu item in any of the menus available to any user
    • part of a process flow that the user has access to
    • a start object through user group preferences in IAM, even when all of the other points are false
  • Most importantly though, tasks that are not available anywhere will still have an API available in Indicium, if the user has permission to it. Subroutines with the API checkbox off will never have an API, regardless of permissions. Again it is just much simpler to ensure that end users cannot execute them themselves.
  • Tasks and task parameters have a lot of fields in the SF that are not relevant when you’re trying to use it in the same way as a subroutine. I would even say that the majority of the fields are irrelevant in this case. It is a better user experience to create a subroutine.
  • As an aside, subroutines are easier to debug, because you know they can't have application logic, parameter accessibility or things like lookups with prefilters that cause unforeseen issues.

I hope this helps.

Reply


Terms & ConditionsCookie settings