Ignore BPM while uploading parts via DMT



I have created a BPM on part creation, which it will assign a new part number based on some criteria. But I do not want that when I upload parts via DMT, that this BPM is run.

Is there any way we can do it?


If it is a one off, you could always disable the directive before you run the upload.

Alternatively, create a UD field on Part (e.g. LoadMethod_c) add this to your upload file and then check for this in your BPM, using a condition like If LoadMethod_c = ‘DMT’ the return false.

The condition I have now it is that if number of added records = 1, run bpm, else do nothing.

I did that cause I though BPM would be on batch, but it looks like it runs record by record, thus triggering the bpm on each iteration.

I like your suggestion, but I think it is better to do the opposite, and not expect the field to be set on the DMT (the user running DMT may not know about this trick)

So I rather set the LoadMethod to ‘Manual’ when creating the part from the part form (I remember seeing something like that).

And in the BPM check if its Manual to execute it, else do nothing.

Whish there was a simpler solution, like process running = “DMT” or something like that, oh well.

Thanks for your input, it was a clever workaround. If no other more direct approaches are suggested, I will set yours as solution.

I’ve created a user (I called it DMT) for that sole purpose. Then I add a condition (Session.UserId <> ‘DMT’) where I don’t wan’t the bpm to be trigger. No UD field required.

1 Like

The good thing about this solution is that you can use it in any table / trigger without the hassle of having to create a custom field each time.

But on the other hand there is a risk of someone in the future to upload it with a different user. Nevertheless I think that for now I will use this approach, and remove the DMT permissions from all admin users.

Thank you.

You can take Louis’s idea and use Security Group membership as a condition where the DMT user is always in it but you can add and remove others as needed.

1 Like

I think that to avoid issues, is better than only the DMT user has DMT permissions. I don’t see a reason to create a group, but maybe I did not understand your point.

In a Data Directive, one can add a condition that the user belongs/does not belong to a security group. Hardcoding names into the condition means having to have to change the code for a different user. It’s much faster to add or remove a user from a group than update code. Managing by a security group gives you the solution that Louis provided with the added flexibility of changing users without code changes. This handles the concern you posted above:


ah ok, I get it, this is if we want to have more than one user uploading via DMT. But this can cause an odd behavior if the same user creates a part manually (Bpm won’t run) because he also belongs to the DMT group.

What I think that would give a definitive solution, is that only a DMT user had permissions to run DMT scripts. This user would be for that sole purpose. But I agree it could be a group instead, in case in the future we want to have dmt1, dmt2, etc…

Thanks a lot for your input.

1 Like

Correct. But that’s the beauty of groups. Add the user. Run the DMT. Remove the user. It could even be scripted.

1 Like

I think I got this idea from @josecgomez. I don’t have much credit.

We can credit you being faster than Jose with the right response! :rofl:


You can also use the condition on the calling assembly…I’ve used that before to determine if the bpm needs to be fired only when that particular action is fired from a handheld.