SLAs in Domain Separated Instance - SLAs treated as Data or Process?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-27-2016 06:18 AM
In Domain Separated instance, are SLAs treated as Data OR Process?
I have set use_record's_domain sys_properties to false. This means that data and process should be rendered based on current user's domain. It should never use record's domain. For SLAs, I found that whenever an task_SLA is created or updated, its domain changes to current record's domain. Do you know why?
I would want the SLAs to remain in the domain they were defined (in SLA definition). For example, if an SLA is created in Domain for Vendor A, no matter what the current user's or record's domain is, the task_SLA must be created in Vendor A domain and should always remain in Vendor A domain. So that only Vendor A can see their task_sla records.
Do we need to write AFTER business rules for these? (That seems like a workaround).
Additional Information:
domain hierarchy:
TOP --> Sector 1 --> Vendor A
TOP --> Sector 1 --> Vendor B

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-27-2016 07:41 AM
There's other system properties to consider, like use record domain for data & for process.
SLA's are typically defined at TOP and then if needed, add additional trigger conditions versus putting into specific domains.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-27-2016 02:01 PM
The task_sla are definitively data.
I won't have time to elaborate but "if 'So that only Vendor A can see their task_sla records.' is important, it's maybe not only the task_sla you should protect but the whole task" (Because as Vendor B, if I have access to the task, I would be able to find out a good approximation of the SLA based on the timestamps of the records).
So, this issue isn't your root cause, barely a symptom. You probably need to investigate on the functional and organizational context to be sure the design is compliant with the requirements.
But on a pure technical solution (eq: acting as if this is the only issue we need to fix), an onBefore business rule on the task_sla table with a high order will be largely better than an onAfter business rule because we wouldn't add additional .update()