Community Forum

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?

Hi, Is there documentation about the bank details that can be added to a beneficiary? Thanks

Good day Is there a way to not bump the terms.pdf but only bump the code for a product module? The reason is we would have to keep previous business on the previous terms but still push them to any new code changes made. We can work around this when there are only 2 versions of a terms.pdf by doing a deploy with the old terms.pdf, bumping everyone and then doing another with just the new terms.pdf and not bumping but this adds overhead for all involved and only works for 2 versions, for 3+ it will not work.

Hi, I'm trying to add a cellphone-style input to the application workflow schema but the available validation and component types don't seem to allow for a component that ends up looking like the ones we see on the policyholder page. See below from the policyholder page:  Please advise how we'd go about adding this. There isn't a component like this documented on the schema component reference docs (<https://docs.rootplatform.com/docs/schema-component-reference#input-components>). Thanks

After pushing version 90.5 to the OneSpark organisation (id d00e0ea4-0ee2-4c08-804d-61df85ca32ec) at 08:47:22 on Oct 31, I created policy number 899D385451 (id 4860bc3f-690f-400d-abb1-7cf7f72bb3ec) around 08:52:19 on Oct 31. I then proceeded to allocate an EFT payment for the policy a few minutes later from the policy details screen (https://app.root.co.za/orgs/d00e0ea4-0ee2-4c08-804d-61df85ca32ec/insurance/policies/4860bc3f-690f-400d-abb1-7cf7f72bb3ec) and then proceeded to cancel the policy. My expected result was that no refund would be allocated since the version pushed contains config which indicates the following: ` "coolingOffPeriod": { "applyTo": { "theFullPolicy": null } }, ` A refund was erroneously created. This is now the 3rd time I've ran this test and each time I end up getting the same result. I'm changing only the .root-config.json file and pushing from local doing `rp push --force`. Is that sufficient in testing this? (This is the way we test all changes before pushing to the dev branch)

Hi, I see from older release notes (<https://docs.rootplatform.com/changelog/root-release-update-january-2022#google-places-autocomplete-for-address-input>) and on the roadmap (<https://portal.productboard.com/root-platform/1-product-roadmap/c/33-google-places-autocomplete-for-capturing-addresses>) the Root supports capturing an address using google integration. 1. Can we get a demo of how this works potentially? 2. What are the costs involved to enable and run this feature? 3. Is there any documentation available for this feature? Thanks

Hi, I'm building an alteration hook whereby we want to change billing information. On the schema I have a field which could either mean company registration number or account holder id number, depending on a select box value. ```json,json Json { "key": "account_holder_id_number", "type": "text", "label": "Account Holder's ID Number", "outputPath": "bank_details.account_holder_id_number", "validators": [ { "validation": { "type": "za_id" } } ], "displayConditions": [ { "path": "id_type", "value": "za_id", "condition": "===" } ] }, { "key": "account_holder_company_registration_number", "type": "text", "label": "Company registration number", "outputPath": "bank_details.account_holder_id_number", "validators": [ { "validation": { "type": "required" } } ], "displayConditions": [ { "path": "third_party_account", "value": true, "condition": "===" } ] }, ``` When submitting the form there are certain case where, if the first field is not displayed, its value is being sent to the API. Is this a known limitation or a bug?

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" } ] ```

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?

Hi there, We need to trigger a custom notification when an external payment method is added to a policy. From the documentation I cannot see if there is a lifecycle hook for payment methods added. I do see there is an event `payment_method_added_event`. Is it possible to hook into this event in the in the Product module code?