Community Forum

Good day 1. What is the default sort order of [this endpoint](https://docs.rootplatform.com/reference/list-all-policies-1)? 2. Is there a way to change this sorting? 1. I see when inspecting the network panel that for some endpoints there is an optional `sort[date_field_name]=desc` column. Can this be added to this endpoint too?

Good day, We have been battling to work out how to get the payments API to work as expected. We either get failure reasons for payments to pull through to the UI and then no comms fire or we get comms to fire but then our async updates to failure reason does not work. An example of a policy where we have this is here: <https://app.root.co.za/orgs/f0f74964-62a3-4bf1-9077-e6059a5c2ae2/insurance/policies/693814b4-fa55-4db7-b6a1-b7857eef0c95> 1. For the first payment (comms fire, failure reason not pulling through with an update): 1. We created the payment with a FAILED status, we then tried updating it using the payments endpoint and the job returned an OK 1. The payment did not update as far as we can see to include the failure reason we sent 2. The email and SMS comms did fire 2. For the second batch (comms don't fire, failure reason does pull through with an update) 1. We create the intial payments in PROCESSING or SUBMITTED 2. We then update using the update endpoint 1. The update to add the failure reason (as the creat endpoint does not allow it to be specified) does not result in the payment object updating at all 2. The SMS and email comms do fire 3. Emails and SMS do not fire 4. The failure update reflects both on the object and the UI 1. The updated at does not change 2. The finalized at does seem to have changed 3. Everything on the update object is required (the docs say only payment_id and status are required) Can you please assist with the above? Additionally, is there a DELETE endpoint? If not how would we delete payments if we needed to? I don't have the first payment's create and update requests but the second batches are: Create the initial payments ``` [ { "status": "submitted", "payment_type": "premium", "premium_type": "recurring", "amount": 123, "description": "Failed-Test-submitted-premium-recurring-do-2-day", "payment_date": "2022-10-10T00:00:00.000Z", "collection_type": "debit_order_two_day", "external_reference": "233c9210-submitted-premium-recurring-do-2-day", "policy_id": "693814b4-fa55-4db7-b6a1-b7857eef0c95" }, { "status": "processing", "payment_type": "premium", "description": "Failed-Test-processing-premium-recurring-do-2-day", "premium_type": "recurring", "amount": 456, "external_reference": "233c9210-processing-premium-recurring-do-2-day", "payment_date": "2022-10-10T00:00:00.000Z", "collection_type": "debit_order_two_day", "policy_id": "693814b4-fa55-4db7-b6a1-b7857eef0c95" } ] ``` Update the above payments ``` [ { "payment_id": "6b13355f-8c38-4efb-9ced-8db4bf118eb0", "status": "failed", "failure_reason": "Account closed - Failed-Test-submitted-premium-recurring-do-2-day", "failure_action": "block_payment_method" }, { "payment_id": "d2d85efa-f209-4bb1-94df-2df1b0fee441", "status": "failed", "failure_reason": "Account closed - Failed-Test-processing-premium-recurring-do-2-day", "failure_action": "block_payment_method" } ] ```

Hi we often need to know the details of the person behind the id for a created_by For example we get back: ``` //... "created_by": { "type": "user", "id": "00000000-0000-0000-0000-000000000001" }, //... ``` How would we get the name and details of created_by.id above programmatically?

Hi we are looking to pull payments off of a policy We are looking at the docs [here](https://docs.rootplatform.com/reference/retrieve-policy-payments-1) The issue is the response object has 20+ fields but the documentation is limited: 1. There is no indication of nullability 2. Most things are strings e.g. created_at is marked as a string) 3. Nested objects have no definition Can you please advise on details of what a policy payment looks like for the above points?

I know `app_data` can be used on certain entities like `policy` and policy_holder` to add arb JSON data where it is not managed by the platform Is this the case for all entity types or just some? If it is just some can they please be documented in the answer or/and the documentation?

Good day We have started using the new [payments API](https://docs.rootplatform.com/reference/create-payment) What is not clear is what events fire off of the different permutations of the payment object sent through successfully. What events/communications are fired for the following? 1. payment_type 1. premium_type 1. collection_type Do we need to use collection_type = debit_order_* to fire off the debit order comms? * If we do use a debit_order_* type other than comms are there any other things that happened (bear in mind this is for a payment being fed in where the product module is configured to external payments)?

My understanding is that on Root anniversary events and communications are configured to run based on the start date of the policy. For the first anniversary this makes sense, but for subsequent anniversaries is the start date month and day used or is there some other nuance to it?

We are trying to test schedule functions on sandbox and have a few questions around this: 1. Do sandbox schedule functions behave the same as production? 1. So they are GMT+0 and they run roughly around time GMT+0 and get queued? 2. Can we look at the execution logs for schedule function logs? 1. We are not seeing our console.logs showing there - assuming the schedule function is actually running in sandbox 3. Are there any other differences between schedule functions across sandbox and production? 4. Is there an easy way to test them or do we just need to let them run in sandbox? 5. The docs are still not 100% clear to me, is the payload you return (assuming it is not a blank return to bypass calling it) the desired structure you want the policy to look like? 1. To be safe we are spreading everything on the policy and mutating the actual fields we want, so we use something like ```javascript // data: { ...policy, module: { ...policy.module, benefits: moduleBenefits //this is the thing we actually want to mutate but don't want to wipe the rest of the policy } } ``` // data: { ...policy, module: { ...policy.module, benefits: moduleBenefits //this is the thing we actually want to mutate but don't want to wipe the rest of the policy } }

Hi There We have a requirement where we need the error messages shown on the dashboard to not suffix our errors with `Please try again or contact [email protected] if the problem persists` Is this possible and if so how? In our case the errors are business specific errors to us, Root support will be flooded with tickets they cannot assist with. Our error messaging directs user's what to do and who to contact but the suffix will cause confusion

Hi, In our unit-testing-code.js, we're trying to test some code which accesses a datastore, as in the example: `await root.dataStores.store('data_store_key').find();` Unfortunately, the `root` object is always undefined. Am I failing to setup the test correctly? Thanks