Managing Enterprise Customers on Console

Hello Particle Community,

I am building a product that will be used for enterprise customers. Each enterprise customer will have certain devices assigned to them but I want to conduct the assignment prior to shipment rather than the customer having to “claim” the devices upon receipt. Due to the fact that we manage all the account creation and device management, I have a few questions regarding how to best use the console.

  1. Can I create the customer accounts myself through the console and assign the devices to those customers on my side without the end customer having to do anything regarding the claiming of the devices? Anyway to efficiently do this without having to create multiple particle customer accounts?
  2. Can I unclaim and reclaim devices to other customers if devices are returned for refurbishments? Can this all be done through the console without the devices needing to connect to wifi?
  3. Can I send firmware updates on a per customer basis rather than on a per product basis? I need to keep all my devices as one product id so that flashing on the manufacturing line becomes easier.

Thank you!

Hi @sdinnu,

Great questions / suggestions! I forwarded this on to our team. :slight_smile:


Hey @sdinnu,

Great question. I’m Jeff, a product manager at Particle. I want to break down my answers into two parts: what is possible right now, and what will be possible in the future.

So, first, what’s possible now. Currently, you can create customers through the API. There is no UI for the console to do this. Here is the API documentation to do this. Our architecture right now is set up in such a way that if you are using customers, we assume they will be setting the device up and “claiming” it. If you are not building a product like this, using customers might not make sense (in the way it’s currently implemented).

To your second question: Yes, unclaiming and reclaiming devices is possible on the console. You can do so on the devices page for your product:

You can send firmware updates on a per-customer basis, but what this would really look like is doing so on a device-by-device basis. You would first get a list of all the devices owned by a customer, then iterate through each one and call the firmware flash endpoint. However again, your use case sounds like it might not be suited for use of customers in the way we’re thinking about it right now.

OK, now let’s talk about long-term. What you seem to really be asking for is a way to divide your fleet into sub-groups, and access/manage those sub-groups separately. This is a feature that we are currently seriously considering internally, as more and more use cases for this are coming up. If I may, I’d love to think about how your problems could be solved if we had a feature like this. I’ll divide it up by your questions:

  1. You could create one account per customer, and give that account access to a group of devices in your fleet. In your case, you could create one customer per enterprise, and associate all devices with the customer with a group. No claiming would need to happen, that customer would have access to the group of devices needed

  2. At any time, you could add/remove devices from a group, so the customer would instantly gain or lose access to devices in the case of returns and refurbishments

  3. Firmware could be released and delivered on a per-group basis, allowing you to divide up the fleet effectively and get the right firmware to the right customer

Now, this architecture is still very much being brainstormed/considered internally, and nothing is set in stone. However, how does that feel to you? Would something like this solve your problem?

1 Like

Thank you Jeiden for the comprehensive answer. I do agree that after further exploration, utilizing the console as it is today does not come with many benefits. You hit our requirement on the head in regards to being able to divide our fleet into subgrounds and manage those groups separately. For example you guys discuss having a test group before you roll out firmware, but right now flashing the test group is a one-by-one process. It would also be great to have hierarchy to those groups so we have more control in regards to how the flash the fleet.

I would love to stay involved in the design of this process since without this level of control, I am better off not utilizing console at all, and just managing my fleet using the CLI tool + old school excel based device management. Please reach out as needed.