If a business rule is created in a certain domain on a domain-separated table, it's likely that it won't run if you set it to 'after' except under certain conditions. It will, however, run as a 'before' business rule.

Domain-separated tables have a business rule called "Domain - Set Domain - [table]" which sets the domain of inserted/updated records. What it gets set to depends on the table. For example, the Task table's domain BR sets the domain to be equal to the domain of the company in the Company field. Other tables may do something different. Before the record is inserted, the domain will be equal to the current user's domain. If it is being updated, the domain will be the previous domain until after the update. After the record is inserted/updated, it may be in a completely different domain.

Let's say you have a 'before' insert/update business rule on Task which is in the TOP/SNC domain. If you change your domain to TOP/SNC and insert a record into Task, the business rule will run because its domain will match yours before it's inserted. Now let's say you change it to an 'after' business rule. If you then go and update that record with no value in the Company field, or select a company in a domain other than TOP/SNC, the business rule will not run. This is because the domain will be set to the company's domain (global if no company is specified) and the record will no longer be affected by business rules in the TOP/SNC domain.

It is important to keep in mind that just because you are in a certain domain, it doesn't necessarily mean all records you create will be in that domain. This behavior differs from that of application scopes, where all records will be created in that scope. If you are experiencing domain-related issues when creating records, check the "Domain - Set Domain - [table]" business rule on that table.