Location awereness in code context

Hi Freddy,

Could you elaborate on the Use case? Is your idea similar to this one?: 

• variant_id for layouts, contexts, defaults, handlers On the backlog
• 46 Votes

Not entirely, the point is you want to use the model to have one task that is shown on for example 5 different table (variants). Although the principle function is the same, different screens usually mean different roles and thus small differences in business logic. So it would be great to have a variable for every position (in the model like a table, variant) where it is shown. So we can use this knowledge that if the task is activated from table A it inserts slighty different information then when it is executed from table B. 

Now sometimes you have to make 6 seperate tasks for what could be just one taks if just I have an @table_a , @table_b (so I can steer my data)..  even better would be if  these variables are filled with a 1 or 0 for example to have knowledge on it's execution origin. 

Hi Freddy,

From my experience when working on a partner project, we used to add a "table_id” expression column to the tables that had the table name as value. This value you could then map to a Task parameter and use that value to determine what code to run where. Would that suffice?

As a solution, yes it could be a standard that the SF creates these expression variable with the table and variant so you know it when applying business logic. And if it's not something you want in de SF by default, maybe it would be good to reinstate the Thinkstore here but then for solution examples.. Which for some Thinkstore items could be a better solution..  Feels a bit overkill sometimes to download a full project for just a function for example 😉